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SOA  Provides  Opportunities  and  Challenges 

J  oe  Jarzombek,  the  Department  of  Homeland  Security  (DHS)  Director  for  Software 
Assurance,  stated  that  with  more  organizations  considering  Service-Oriented 
rchitectures  (SOAs)  for  their  applications  and  services  and  with  software  as  a  service 
gaining  traction,  we  need  to  directly  address  the  reality  that  these  are  built  on  software 
applications  and  also  address  factoring  security  needs  into  development,  acquisition, 
and  deployment  decisions.  SOAs  provide  an  avenue  to  develop,  operate,  and  access 
distributed  computing  systems.  While  traditional  quality  and  information  assur¬ 
ance  methodologies  tended  to  focus  on  closed  or  tightly-controlled  monolithic  systems, 
the  reality  of  SOA  has  moved  us  away  from  that  conventional  thinking  and  forced  the 
mainstream  Information  Technology  establishment  to  operate  in  a  complex  distributed 
computing  world. 

SOAs  provide  numerous  conveniences  and  additional  challenges  along  with  those  con¬ 
veniences.  As  the  highlighted  co-sponsor  for  this  issue  of  CROSSTALK,  the  DHS  focus¬ 
es  on  the  security  challenges  of  the  enabling  applications  for  SOAs. 

With  this  important  focus,  we  start  this  month’s  CROSSTALK  with  The  Securitj  of  Web 
Services  as  Software  by  Karen  Mercedes  Goertzel.  In  this  article,  Goertzel  stresses  the  need 
to  focus  on  security  while  developing  the  software  that  enables  SOAs.  We  take  a  step  back 
with  the  following  article  to  focus  on  enablers  of  overall  SOA  success.  Grace  A.  Lewis  and 
Dr.  Dennis  B.  Smith  discuss  developing  an  appropriate  SOA  strategy,  implementing  effec¬ 
tive  SOA  governance,  making  sound  technology  assessments,  and  accounting  for  the  fact 
that  SOA  requires  a  different  mindset  in  Four  Pillars  of  Service-Oriented  A^rchitecture.  Next, 
Michael  S.  Russell  addresses  practical  applications  for  the  warfighter  in  Defining  Services 
Using  the  Warfighter’s  Fanguage.  Mitch  Chan  provides  an  example  of  a  current  successful 
application  in  Applying  a  Service-Oriented  Architecture  to  Operational  Flight  Program  Development. 
In  our  final  article.  For  Net-Centric  Operations,  the  Future  Is  Federated,  ]ohn  Michelsen  suggests 
a  system  intended  to  ease  sharing  of  burden  for  shared  software  services. 

Total  SOA  Assurance  represents  the  merging  of  what  was  considered  distinct  domains 
of  computer  system  assurance.  Quality  assurance,  information  assurance,  and  operations 
are  all  merging  to  a  place  where  one  cannot  exist  without  the  other.  The  buyers  of  tech¬ 
nology  and  consulting  services  around  SOA  must  become  well-educated  consumers.  To 
that  end,  we  should  focus  on  current  and  developing  concepts  around  total  SOA  assurance. 
As  the  nature  of  future  distributed  computing  systems  will  cross  organizational  and  polit¬ 
ical  boundaries,  a  new  framework  of  thinking  about  SOA  needs  to  begin  to  handle  the 
myriad  of  issues  that  surround  interoperation  organizations. 

As  the  increasingly  popular  delivery  scheme,  SOA  provides  the  enabling  framework  for 
software  applications,  yet  it  tends  to  further  separate  the  user  from  the  enabling  software. 
Lest  this  separation  cause  the  community  to  forget  the  challenges  posed  and  faced  by  all 
involved  with  the  software,  the  articles  in  this  issue  of  CROSSTALK  are  intended  to 
bring  some  key  ideas  to  the  forefront. 
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The  Security  of  Web  Services  as  Software 

Karen  Mercedes  Goertzel 
^00^  Allen  Hamilton 

To  help  creators  of  Web  services  and  S ervice-Oriented  Architectures  fSOAsJ  understand  and  address  the  security  challenges 
that  confront  them,  the  National  Institute  of  Standards  and  Technology  (NIST)  is  getting  ready  to  publish  a  new  Special 
Publication  (SP)  800-95,  Guide  to  Secure  Web  Services.  This  SP  describes  Web  service  security  standards  and  explains  how 
to  develop  Web  services  and  SOA  portals  using  technologies  based  on  those  standards.  However,  neither  SP  800-95  nor  the 
standards  it  describes  address  a  critical  challenge:  the  security  of  Web  services  as  software.  Without  considering  software  secu¬ 
rity,  developers  cannot  create  Web  services  that  are  truly  trustworthy.  This  article  describes  both  the  content  of  SP  800-95  and 
highlights  its  critical  omissions  in  terms  of  measures  needed  to  produce  Web  service  software  that  is  in  and  of  itself  secure. 


Web  services  in  SOAs  allow  applica¬ 
tions  to  interact  and  data  to  be 
interchanged  without  direct  human 
intervention.  The  use  by  Web  services  of 
extensible  Markup  Language  (XML), 
SOAP  (formerly  Simple  Object  Access 
Protocol),  and  related  open  standards 
enables  these  interchanges  to  be 
achieved  over  connections  that  are 
established  dynamically  on  an  ad-hoc 
basis. 

Web  service-based  SOAs  are  prolif¬ 
erating  exponentially,  both  in  number 
and  extent,  in  Department  of  Defense 
(DoD)  and  other  government  agencies, 
the  private  sector,  and  academia.  Web 
services  are  relied  on  to  create,  manipu¬ 
late,  and  protect  information,  including 
the  most  sensitive  private  information. 
They  are  used  to  perform  high-conse¬ 
quence  and  mission-critical  information¬ 
handling  functions. 

The  individual,  software-intensive 
Web  services  of  which  these  SOAs  are 
composed  are  also  growing  larger  and 
more  complex,  to  the  extent  that  their 
own  developers  can  no  longer  fully  rec¬ 
ognize  —  let  alone  comprehend  —  all  of 
their  possible  behavioral  states,  weak¬ 
nesses,  and  vulnerabilities. 

At  the  same  time,  software-level 
threats  to  Web  services  and  portals  to 
SOAs  are  increasing  in  intensity,  sophis¬ 
tication,  and  variety.  Zero -day  vulnera¬ 
bilities  in  commercial  Web  service  soft¬ 
ware  products  have  not  only  been 
proven  to  exist,  they  are  on  the  rise.  (A 
zero-day  vulnerability  is  one  against 
which  an  exploit  is  launched  by  an 
attacker  before  a  security  patch  can  be 
issued  by  the  product’s  developer.) 

The  security  challenges  presented  by 
the  Web  service  processing  model,  in 
which  SOAP  messages  encapsulating 
sensitive  XML  documents  are  forwarded 
along  complex  chains  of  consumer. 


provider,  and  intermediary  Web  ser¬ 
vices,  are  formidable.  This  is  because 
many  of  the  features  that  make  Web  ser¬ 
vices  and  SOAs  attractive  —  greater 
accessibility  of  data,  dynamic  establish¬ 
ment  of  interservice  relationships  and 
communication  paths,  a  high  degree  of 
service  autonomy,  and  a  minimal 
amount  of  direct  human  involvement  — 
are  all  at  odds  with  traditional  security 
models  and  controls. 

The  nature  of  Web  services  and 
SOAs  makes  them  subject  to  unique 
attacks,  as  well  as  variations  (often 
involving  intensification)  of  familiar 
attacks  that  already  target  Web  servers 
and  applications.  Achieving  secure  Web 
service  processing  entails  the  extension 
and  augmentation  of  existing  Web  and 
Internet  security  mechanisms.  This  is 
increasingly  achieved  through  the  imple¬ 
mentation  of  authentication,  authoriza¬ 
tion,  trust,  confidentiality,  integrity,  and 
availability  of  functions  based  on  rela¬ 
tively  new  and  still-emerging  Web  ser¬ 
vices  security  standards. 

NIST  SP  800-95,  Guide  to 
Secure  Web  Services 

To  help  the  architects,  developers,  and 
engineers  involved  in  the  creation  of 
Web  services  and  SOAs  understand  and 
address  the  security  challenges  that  con¬ 
front  them,  the  NIST  is  publishing  a 
new  SP  800-95,  Guide  to  Secure  Web 
Services.  The  current  draft  of  SP  800-95 
can  be  downloaded  from  the  SP  page  of 
the  NIST  Computer  Security  Resource 
Center  Web  site:  <http://csrc.nist.gov/ 
publications/nistpubs/>.  The  final  ver¬ 
sion  will  be  published  at  this  address 
later  this  year. 

The  objective  of  this  NIST  SP  is  to 
describe  and  make  sense  of  the  broad 
range  of  Web  service  (WS)  security  stan¬ 


dards  that  have  been  produced  by  the 
Organization  for  the  Advancement  of 
Structured  Information  Standards, 
World  Wide  Web  Consortium,  Web 
Services  Interoperability  Organization 
(WS-I),  the  Liberty  Alliance,  and  other 
standards  bodies.  Because  of  this  objec¬ 
tive,  the  SP  tends  to  focus  on  security 
issues  that  are  already  being  addressed 
by  these  various  standards  bodies  and 
omits  discussion  of  those  security  chal¬ 
lenges  that  have  not  yet  been  acknowl¬ 
edged  by  the  standards  community,  or 
that  the  community  has  deemed  unimpor¬ 
tant,  out  of  scope,  or  too  hard  to  address  via 
Web  services  security  standards. 

While  SP  800-95  does  describe  how 
to  implement  security  functions  and 
protections  for  Web  services  and  SOA 
portals,  it  does  so  almost  exclusively 
from  the  point  of  view  of  what  can  be 
achieved  using  technologies  based  on 
current  and  emerging  Web  services 
security  standards. 

Unsurprisingly,  after  providing  back¬ 
ground  information  on  key  Web  services 
and  SOA  concepts,  capabilities,  and 
components,  including  discovery,  mes¬ 
saging,  portals,  coordination  (choreogra¬ 
phy  and  orchestration),  and  the  roles, 
modes,  and  properties  of  Web  services, 
the  SP’s  discussion  is  limited  to  what  is 
already  widely  accepted  as  constituting 
Web  services  security',  secure  interservice 
messaging,  protection  of  XML-based 
content,  secure  negotiation  of  contracts 
between  service  providers,  and  estab¬ 
lishment  of  trust  relationships  between 
services. 

For  each  of  the  security  capabilities 
and  protections  it  introduces,  the  SP 
describes  the  associated  Web  services 
security  standards.  These  standards  are 
organized  into  a  stack  (comparable  to 
the  Open  Systems  Interconnect  [OSI] 
and  Transport  Control  Protocol/ 
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Internet  Protocol  network  protocol 
stacks).  Within  an  SOA,  the  standards 
are  also  frequently  implemented  within 
core  security  services,  i.e.,  security  ser¬ 
vices  that  other  services  depend  on  to 
perform  essential  functions  on  their 
behalf.  The  SP  also  describes  the  securi¬ 
ty  threats  to  Web  services  that  protec¬ 
tions  and  functions  based  on  these  stan¬ 
dards  are  intended  to  address.  These 
functions  and  protections  fall  into  eight 
general  categories: 

1.  Authentication  and  identity  man¬ 
agement.  The  SP  addresses  service- 
to- service  authentication  and  service, 
and  identity  management  and 
authentication  of  human  users  who 
access  SOAs  via  Web  portals. 
Specific  standards  discussed  include 
WS-Security  for  inter  service  authen¬ 
tication  (including  its  security  short¬ 
comings),  and  Security  Assertion 
Markup  Language  (SAML)  as  the 
basis  for  single  sign-on  by  human 
users. 

2.  Interservice  trust.  The  SP  address¬ 
es  trust  establishment  (based  on 
authenticated  identity)  between  ser¬ 
vices,  and  federation  of  trust  across 
SOA  boundaries. 

3.  Secure  service  discovery.  The  SP 

focuses  on  security  for  Universal 
Description,  Discovery  and  Integra¬ 
tion  (UDDI)  and  Web  Service 
Description  Language  (WSDL)  inter¬ 
faces,  secure  access  to  the  SOA  reg¬ 
istry,  secure  interaction  of  Web  por¬ 
tals  with  the  SOA  discovery  services, 
and  application  programmatic  inter¬ 
faces  (APIs)  for  secure  service 
inquiry  and  publishing. 

4.  Distributed  authorization  and 
access  management.  The  SP  dis¬ 
cusses  the  authorization  of  privileges 
to  Web  services  and  the  enforcement 
of  least  privilege  in  SOA  authoriza¬ 
tion  models.  Specific  standards  dis¬ 
cussed  include  SAML  as  the  basis  for 
asserting  privileges,  extensible 
Access  Control  Markup  Language 
(XACML)  as  the  basis  for  service- 
level  access  control,  and  the  use  of 
XML  schema  and  security  metadata 
for  data/content-level  access  control. 

5.  Confidentiality  and  integrity  of 
service-to-service  interchanges. 
The  SP  discusses  use  of  HyperText 
Transport  Protocol  Secure  (HTTPS) 
for  transport  layer  security  in  SOAs, 
WS-Security  for  SOAP  message-level 
security,  XML  encryption  and  signa¬ 
ture  for  content  protection,  and  the 
role  of  XML  gateways  in  providing 
additional  message-level  and  content- 


level  integrity  protection. 

6.  Accountability.  The  SP  discusses 
methods  for  achieving  accountability 
end-to-end  throughout  a  Web  service 
chain,  including  audit  in  SOA  environ¬ 
ments  and  use  of  XML  signatures  as 
the  basis  for  non-repudiation  of  Web 
service  transactions. 

7.  Availability  and  quality  of  service 

(QoS).  The  SP  discusses  availability 
and  QoS  techniques  such  as  fail-over, 
handling  of  service  deadlocks  and  ser¬ 
vice  recursion,  and  it  addresses  the 
security  implications  of  competing 
reliable  messaging  standards. 

8.  Security  policy  specification.  The 
SP  discusses  WS-Policy  and  its  role  in 
supporting  specification  and  enforce¬ 
ment  of  security  policy  within  an 
SOA. 

Recognizing  that  standards  are  only 
the  basis  for  implementations,  the  SP 
touches  on  tools  and  technologies  for 

^^What  Web  service 
software  does  share 
with  other  software  is 
its  exposure  to  threats 
throughout  its  lifetime, 
not  just  after  it  has 
been  deployed,  but 
while  it  is  still  under 
development.^* 


implementing  security  standards-based 
Web  services,  such  as  Web  service-orient¬ 
ed  developer  toolkits,  XML  parsers,  pro¬ 
cedural  languages  commonly  used  in  Web 
service  development,  XML,  and  tools  and 
techniques  for  testing  the  security  of  Web 
services. 

In  this  context,  the  SP  also  addresses 
issues  associated  with  secure  Web  service 
enabling  of  legacy  applications  (e.g.,  pub¬ 
lic-key  enabling  consistent  with  Web  ser¬ 
vices  standards  and  implementing  stan¬ 
dards-based  security  functions  and  protec¬ 
tions  for  legacy  applications  and  databases 
exposed  as  Web  services). 

Security  ofWeb  Services  as 
Software 

Though  SP  800-95  does  cover  imple¬ 
mentation  of  Web  services  that  are  like¬ 
ly  to  be  called  secure  because  they  are 


based  on  accepted  Web  services  security 
standards,  the  SP  does  not  discuss  what 
is  probably  the  most  important  security 
issue  in  the  implementation  of  Web  ser¬ 
vices  —  an  issue  that  is  not  addressed  by 
any  Web  services  security  standard:  The 
security  of  Web  services  as  software. 

It  can  be  argued  that  because  Web 
services  are  subject  to  the  same  security 
issues  as  all  software,  and  particularly 
network-based  application  software,  no 
discussion  of  the  topic  was  needed  in 
NIST’s  Web  services  security  guidance. 
Indeed,  NIST  excluded  such  a  discus¬ 
sion  as  out  of  scope  exactly  because  the 
need  for  software  security  is  not  unique 
to  Web  services. 

This  is  an  interesting  position  for 
NIST  to  take,  given  that  one  can  argue 
equally  that  requirements  for  confiden¬ 
tiality,  integrity,  availability,  authentica¬ 
tion,  trust,  identity  management,  etc.,  are 
not  unique  to  Web  services  either. 
Moreover,  in  several  cases  the  standards 
that  are  being  used  to  address  these 
requirements  were  never  intended  to  be 
exclusive  to  Web  services.  For  example, 
XML  digital  signature  and  encryption 
are  intended  for  use  with  all  XML  docu¬ 
ments,  not  just  those  exchanged 
between  Web  services.  SAML  and 
XACML,  while  certainly  used  to  imple¬ 
ment  authentication  and  access  control 
in  Web  service  implementations,  are 
intended  to  be  widely  applicable  to  all 
types  of  applications. 

Threats  to  Web  Service  Software 

What  Web  service  software  does  share 
with  other  software  is  its  exposure  to 
threats  throughout  its  lifetime,  not  just 
after  it  has  been  deployed,  but  also  while 
it  is  under  development.  Threats  to  soft¬ 
ware  in  development  may  be  intentional, 
coming  from  malicious  developers  who 
subvert  or  sabotage  the  software  they  or 
their  colleagues  build,  or  they  may  be 
unintentional,  introduced  by  developers 
who,  due  to  ignorance,  carelessness,  or 
pressure  to  get  the  software  out  on  time 
fail  to  implement  checks  and  controls 
that  would  eliminate  or  minimize  expo¬ 
sure  of  the  software’s  numerous  weak¬ 
nesses  and  vulnerabilities. 

Compounding  this  problem  is  the 
almost  universal  use  of  commercial  and 
open  source  software  components  in  the 
building  of  Web  services.  The  pedigree 
of  such  components  is  often  a  mystery. 
Neither  the  processes  used  to  develop 
those  components,  nor  the  security 
properties,  weaknesses,  and  vulnerabili¬ 
ties  of  the  components  themselves  are 
ever  investigated  by  the  developers  who 
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incorporate  those  components  into  their 
Web  services.  Even  pedigree  of  open 
source  components  is  taken  entirely  on 
faith.  Just  because  open  source  code  is 
available  for  review  does  not  mean  that 
anyone  actually  does  code  reviews  of 
open  source  code. 

Specific  threats  to  Web  services 
under  development  fall  into  two  general 
categories:  1)  malicious  code,  and  2) 
exploitation  of  weaknesses  and  vulnera¬ 
bilities. 

1.  Malicious  code.  Logic  bombs,  time 
bombs,  Trojan  horses,  worms,  and 
other  undocumented  malicious  func¬ 
tions  are  intentionally  inserted  into 
the  source  code  or  appended  to  the 
binary  executable  by  the  developer. 
Failure  to  review  source  code  and 
carefully  observe  the  behavior  of 
executing  binary  code  means  that 
such  embedded  malicious  code  will 
be  allowed  to  remain  in  software 
when  it  is  deployed.  Furthermore, 
malicious  code  may  be  added  by  an 
attacker  who  intercepts  and  tampers 
with  electronically  distributed  exe¬ 
cutables.  After  the  software  is 
deployed,  it  is  subject  to  the  delivery 
of  new  malicious  code  or  the  execu¬ 
tion  of  embedded  malicious  code. 
The  risk  of  malicious  code  insertions 
and  executions  is  increased  when  the 
software  and  its  environment  are  not 
configured  insecurely,  and  anti-mali- 
cious  code  countermeasures  are  not 
deployed  or  used  effectively. 

2.  Exploitable  weaknesses  and  vul¬ 
nerabilities.  Flaws,  defects,  errors, 
and  faults  are  often  included,  usually 
unintentionally  but  sometimes  inten¬ 
tionally,  in  the  artifacts  —  specification, 
architecture,  design,  or  implementa¬ 
tion  -  of  the  Web  service.  In  some 
cases,  these  can  be  intentionally  lever¬ 
aged  by  attackers  (or  by  malicious  soft¬ 
ware  processes  acting  on  an  attacker’s 
behalQ  to  compromise  the  security  of 
the  Web  service  itself  or  of  the  data  it 
handles. 

Weaknesses  originate  as  early  as  the 
requirements  phase.  Security-related 
requirements  may  be  overlooked  or 
misstated,  or  spurious  requirements 
may  be  included.  They  may  arise  as  the 
result  of  poor  architecture  or  design 
choices,  such  as  failure  to  enforce  least 
privilege  or  to  design  in  redundancy  of 
critical  processes. 

Vulnerabilities  may  enter  software 
during  its  implementation,  due  to  use 
of  non-secure  implementation  prac¬ 
tices.  Examples  of  such  practices 
include:  accepting  user  input  without 


first  validating  it;  using  vulnerable 
technologies  (e.g.,  SOAP  over  unen¬ 
crypted,  unauthenticated  HTTP  con¬ 
nections);  use  of  non-secure  pro¬ 
gramming  languages  (e.g.,  non-type- 
safe  languages  used  without  input 
validation)  and  library  functions  (e.g., 
buffer  overflow-prone  C  functions 
such  as  printf);  use  of  non-secure 
development  tools  (e.g.,  compilers 
that  do  not  perform  bounds  check¬ 
ing);  reuse  of  vulnerable  compo¬ 
nents  (e.g.,  commercial  software  that 
has  known  vulnerabilities);  use  of 
development  tools  (e.g.,  compilers 
that  do  not  perform  bounds  check¬ 
ing);  or  reuse  of  vulnerable  compo¬ 
nents  (e.g.,  commercial  software  that 
has  known  vulnerabilities). 

Weaknesses  and  vulnerabilities  may 
be  allowed  to  remain  in  software  due 
to  the  failure  to  perform  adequate 
security  reviews,  assessments,  and 
tests  of  the  artifacts  of  the  develop¬ 
ment  process  (from  specifications 
through  the  software  itself);  or  the 
intentional  tampering  with  the  results 
of  such  reviews/assessments/tests. 

They  may  also  be  allowed  to  remain 
in  the  form  of  back  doors  and  trap¬ 
doors  that  are  not  removed  prior  to 
software  distribution.  They  may  arise 
or  fail  to  be  mitigated  due  to  specifi¬ 
cation  of  non-secure  configuration 
parameters  for  the  software  and  its 
environment  (or  the  use  of  non- 
secure  installation  procedures, 
scripts,  and  tools). 

Once  the  Web  service  is  operational, 
it  is  subjected  to  misuse  by  its  intended 
users,  and  abuse  by  attackers. 
Understanding  the  attack  patterns  to 
which  Web  services  are  likely  to  be  sub¬ 
ject  can  be  extremely  helpful  to  the 
developer  in  specifying  security  require¬ 
ments,  architectural  characteristics,  and 
design  properties  that  can  reduce  a  ser¬ 
vice’s  exposure  and  vulnerability  to  like¬ 
ly  attack  patterns.  Moreover,  such  under¬ 
standing  provides  a  basis  for  defining 
the  code  assessment  criteria  and  security 
test  plans  for  developmental  and  non- 
developmental  Web  service  software 
components  (i.e.,  attack  surface  defini¬ 
tions  highlight  specific  targeted  security 
flaws  to  look  for  during  code  reviews; 
misuse  and  abuse  cases  can  be  elaborat¬ 
ed  into  white-box  and  black-box  test 
scenarios). 

Exploits  Against  Web  Services 

The  exploits,  or  attacks,  that  target  exist¬ 
ing  Web  services  fall  into  two  main  cate¬ 
gories:  direct  and  indirect.  Direct  attacks 


exploit  known  or  suspected  vulnerabili¬ 
ties  and  weaknesses  in  the  Web  service 
itself,  while  indirect  attacks  may  target 
the  service's  interface  with  the  environ¬ 
ment  and  middleware  components  on 
which  it  relies,  or  its  interface  with  the 
external  services  and  applications  with 
which  it  interacts. 

Attacks  against  Web  services  have 
one  of  three  general  objectives: 

1.  Disclosure.  This  may  be  achieved 
through  reconnaissance  attacks  that 
discover  or  reveal  Web  service  vul¬ 
nerabilities  that  can  be  exploited  by 
other  attack  patterns.  It  may  also  be 
accomplished  through  attacks  that 
bypass  or  cause  denial  of  service  in 
the  Web  service  so  as  to  directly 
access  and  disclose  the  sensitive/pri¬ 
vate  data  handled  by  that  service. 

2.  Subversion.  This  includes  subver¬ 
sion  of  the  service’s  functionality 
(i.e.,  by  direct  tampering,  malicious 
code  insertion/delivery,  command 
injection,  tampering  with  the  state  of 
the  service’s  execution  environment, 
and  intentional  triggering  of  errors 
or  faults  at  the  service  boundary  with 
its  environment),  of  its  data,  or  of  its 
security  assumptions  about  other 
services  (i.e.,  by  an  attacker  or  mali¬ 
cious  process  masquerading  as  an 
entity  or  hijacking  an  entity  that  is 
trusted  by  the  service,  and  thereby 
escalating  its  own  privileges  to  match 
those  of  the  trusted  entity).  It  also 
includes  attacks  that  bypass  or  cause 
denial  of  service  in  the  service  in 
order  to  directly  access  or  tamper 
with  the  data  the  service  handles. 

3.  Sabotage.  This  may  be  achieved 
through  denial-of-service  attacks  on 
the  service  itself,  or  on  the  external 
entities  on  which  it  depends  for  its 
dependable,  secure  operation  (e.g., 
execution  environment  and  network 
components,  core  security  services, 
and  defense-in-depth  protections). 
An  objective  of  sabotage  is  often  to 
bring  down  or  bypass  the  targeted 
software  in  order  to  directly  access 
the  data  in  control. 

Particular  Security  Challenges  for 
Web  Services  in  SOAs 

Some  security  challenges  are  unique  to 
Web  service  software,  and  others  are 
greatly  exacerbated  when  they  arise  in 
Web  service  software.  The  chains  of 
dependencies  between  autonomous, 
dynamically  invoked  Web  services  with¬ 
in  SOAs  are  often  much  more  complex 
than  when  autonomous  software  com¬ 
ponents  are  used  in  more  traditionally 
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distributed  processing  models.  In  most 
distributed  systems,  the  list  of  compo¬ 
nents  that  will  be  invoked,  and  the  order 
in  which  they  will  be  invoked,  in  the 
course  of  completing  a  particular  trans¬ 
action  or  task  is  predefined,  as  to  a  great 
extent  are  the  outputs  of  the  invoked 
components.  In  an  SOA  in  which  ser¬ 
vices  are  dynamically  coordinated 
(through  choreography  or  orchestra¬ 
tion),  it  is  frequently  impossible  to  pre¬ 
dict  in  advance  which  services  will  be 
invoked  by  other  services,  and  in  what 
order  those  invocations  will  take  place. 
In  dynamic  coordinations  that  cross  the 
boundaries  from  one  trust  domain  to 
invoke  services  in  another  trust  domain, 
it  is  especially  hard  to  establish  valid 
security  assumptions  in  advance  about 
the  behaviors,  policies,  and  permissions 
expected  by  the  services  in  the  remote 
domain.  If  a  fault  in  a  Web  service  caus¬ 
es  that  service  to  violate  expected 
behavior  or  policy,  the  results  of  such  a 
violation  have  the  potential  to  propagate 
throughout  the  entire  chain  of  services. 
Because  that  chain  is  unpredictable 
(being  dynamically  established  rather 
than  pre-defined),  the  propagation  and 
impact  of  the  violation  will  also  be 
unpredictable.  The  result  of  a  fault  in 
one  Web  service,  then,  may  compromise 
the  security  and  dependability  of  other 
Web  services  much  further  along  the 
chain,  which  may  make  forensic  analysis 
to  identify  the  true  source  of  the  com¬ 
promise  and  to  trace  all  the  possible 
branches  of  its  progress  extremely  diffi¬ 
cult  (if  not  impossible). 

Moreover,  in  SOA  implementations, 
each  service  is  inherently  dependent  on 
other  autonomous  services.  The  increas¬ 
ingly  widespread  use  of  what  are  termed 
core  security  services  model  means  that 
many  innately  non-secure  Web  services 
depend  on  other  services  for  critical 
security  protections  and  capabilities. 
Their  role  as  security  service  providers 
means  that  these  core  services  are  not 
only  the  most  critical  services  in  the 
SOA,  but  represent  the  highest-value 
targets  to  attackers. 

Even  when  provided  via  core  securi¬ 
ty  services,  the  SOA’s  security  functions 
and  protections  are  often  actually  imple¬ 
mented  using  the  security  functions  and 
protections  provided  by  the  underlying 
application  framework,  e.g.,  Java  Enter¬ 
prise  Edition  or  .NET.  This  increases 
the  risk  that  consumer  Web  services  not 
based  on  the  same  framework  technolo¬ 
gies  may  not  interoperate  seamlessly 
with  the  core  security  services.  The  cen¬ 
tralization  of  the  SOAs  security  func¬ 


tions  into  a  set  of  core  services  increas¬ 
es  the  imperative  to  ensure  that  such  ser¬ 
vices,  which  will  be  trusted  to  guarantee 
the  entire  SOAs  security  posture,  will  be 
able  to  resist  or  tolerate  attacks  and  to 
continue  operating  reliably  under  hostile 
conditions.  If  such  software  contains 
weaknesses  and  vulnerabilities  that  can 
be  exploited  by  attackers,  this  model  col¬ 
lapses  due  to  the  misplacement  of  trust 
in  components  that  are  too  vulnerable  to 
perform  their  designated  tasks. 

A  number  of  other  factors  unique  to 
Web  services  and  SOAs  make  their  soft¬ 
ware  components  more  vulnerable  to 
software-level  exploits  than  other  types 
of  application  software.  First  and  fore¬ 
most  among  these  are  the  following: 

1.  The  woefully  inaccurate  assumption 
that  Web  service  interfaces  will  be 
used  only  as  intended  by  other  Web 
services,  and  not  by  human  beings  or 

^^Understanding  the 
attack  patterns  to 
which  Web  services  are 
likely  to  be  subject  can 
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specifying  security 
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architectural 
characteristics,  and 
design  properties  that 
can  reduce  a  service's 
exposure  ... 

malicious  processes.  Because  Web 
services  generally  have  no  direct 
human  interfaces,  their  operation 
receives  little  if  any  human  scrutiny 
or  intervention  ...  except  attackers. 

2.  The  unavoidable  fact  that  by  expos¬ 
ing  Web  services  applications  and 
databases  that  were  never  originally 
intended  for  direct  public  access,  the 
weaknesses  and  vulnerabilities  of 
those  applications  and  databases  are 
also  exposed  to  public  view. 
Moreover,  the  easy-to-use  develop¬ 
ment  tools  used  by  many  Web  ser¬ 


vices  developers  obscure  the  services’ 
low-level  functionality  from  the 
developer;  it  is  these  low-level  func¬ 
tions  that  often  contain  the 
exploitable  weaknesses  and  vulnera¬ 
bilities  that  are  targeted  by  attackers 
and  malicious  code.  For  example, 
Apache  Axis  2  enables  a  Java  devel¬ 
oper  to  simply  load  his/her  Java 
objects  into  the  Axis  SOAP  engine. 
At  runtime,  it  is  the  SOAP  engine 
that  determines  which  incoming 
SOAP  request  messages  should  be 
routed  to  which  Java  objects.  The 
SOAP  engine  then  translates  those 
requests  into  standard  Java  function 
calls  and  routes  them  appropriately. 
Unless  he/ she  has  expressly  reviewed 
the  source  code  of  the  Axis  SOAP 
engine,  he  /  she  will  have  no  idea 
whether  its  routing  or  translation 
functions  contain  embedded  mali¬ 
cious  logic  that  could  result  in  incor¬ 
rect  routing  of  messages  or  incor¬ 
rectly  generated  Java  calls.  In  the  case 
of  a  commercial  tool,  such  as  Visual 
Studio,  the  ability  to  review  the  tool’s 
source  code  is  not  even  an  option. 
Automatic  discovery  of  Web  services 
in  particular  is  a  feature  of  SOAs  that 
makes  it  easier  for  attackers  to  locate  and 
access  potential  targets.  Publishing  of 
repository  entries  about  services  through 
standard  discovery  interfaces  (WSDL  and 
UDDI)  represents  an  unprecedented  level 
of  public  disclosure  of  service  processing 
details  -  details  that  can  be  used  by  recon¬ 
naissance  attackers  to  craft  much  more 
effective  attacks  on  the  discovered  ser¬ 
vices.  Moreover,  to  accomplish  automatic 
service  discovery,  privileges  must  be 
granted  to  unknown  entities  outside  the 
organization  that  owns  the  services  being 
discovered.  There  is  a  significant  question 
as  to  the  extent  that  entities  outside  the 
SOA,  which  interact  with  services  discov¬ 
ered  inside  the  SOA,  can  be  governed  by 
the  policies  (including  security  policies) 
enforced  for  that  SOA. 

For  example.  Organization  #1,  which 
operates  SOA  #1,  may  mandate  that  all 
Web  service  software  must  undergo  code 
review  and  penetration  testing  before 
being  deployed.  Organization  #2,  which 
operates  SOA  #2,  may  have  no  such  poli¬ 
cy.  So,  if  SOA  #1  establishes  a  federated 
trust  relationship  with  SOA  #2,  there  is 
no  way  for  Organization  #1  to  know 
whether  the  Web  services  in  SOA  #2  con¬ 
tain  exploitable  faults  or  malicious  logic. 
Trust,  as  it  is  defined  for  Web  services, 
(e.g.,  WS-Trust)  refers  solely  to  the  assur¬ 
ance  that  a  given  service’s  identity  has 
been  authenticated  by  a  trusted  third 
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party.  By  this  definition,  trust  has  nothing 
to  do  with  the  authenticated  service’s 
trustworthiness.  The  non-malicious  func¬ 
tioning  and  behavior  of  the  service  must 
be  taken  entirely  on  faith. 

Finally,  all  of  the  security  problems 
associated  with  component-based  soft¬ 
ware  systems  are  also  present  in  service 
choreographies  and  orchestrations,  and 
furthermore,  exacerbated  by  the  increas¬ 
ingly  dynamic  nature  of  service  compos- 
ability.  While  security  assumptions  about 
individual  services  may  be  derived  from 
the  services’  WSDL  descriptions,  and 
when  services  are  combined  in  ways  that 
differ  from  transaction  to  transaction,  it 
is  virtually  impossible  to  establish  (1) 
whether  the  security  assumptions  about  a 
given  service  are  still  valid  and  meaning¬ 
ful  when  that  service  is  instantiated  with¬ 
in  a  given  choreography/orchestration, 
and  (2)  whether  there  are  any  irresolvable 
security  conflicts  between  services  that 
are  dynamically  composed  into  a  chore¬ 
ography  or  orchestration. 

It  is  true  that  some  features  of  Web 
service  technology  actually  help  miti¬ 
gate  security  issues  found  in  other  types 
of  software.  Most  notably,  the  reliance 
of  Web  services  on  platform-indepen- 
dent,  standards-based  APIs  such  as 
WSDL  and  SOAP,  rather  than  using 
proprietary  and/or  platform-specific 
APIs,  makes  it  easier  to  replace  vulnera¬ 
ble  Web  services  quickly  with  less  vul¬ 
nerable  substitutes.  Use  of  standard 
APIs  also  enables  diversity  of  service 
implementations  —  a  secure  design  prin¬ 
ciple  that,  when  coupled  with  redundan¬ 
cy  of  services,  reduces  risk  by  reducing 
the  number  of  services  that  will  be 
compromised  by  an  attack  pattern  tai¬ 
lored  to  exploit  a  specific  vulnerability 
in  a  particular  Web  service  implementa¬ 
tion  (or  product).  The  result  is  an 
improvement  in  availability  because  the 
alternate  services  are  unlikely  to  be  sus¬ 
ceptible  to  the  same  implementation- 
specific  attack  patterns  that  compro¬ 
mised  the  services  they  back  up. 

Building  Secure  Web  Service 
Software 

What  can  be  done  to  make  Web  service 
software  trustworthy?  In  practical  terms, 
trustworthiness  will  be  achieved  by  pro¬ 
ducing  a  Web  service  that  is  dependable, 
not  only  under  both  expected  operating 
conditions  but  also  under  unexpected  and 
intentionally  hostile  operating  conditions. 
It  is  this  dependability  under  unexpected 
hostile  conditions  that  constitutes  soft¬ 
ware  security. 


In  practical  terms,  intentionally  hostile 
operating  conditions  are  created  either  by 
the  presence  of  attack  patterns  or  the 
behaviors  that  result  from  execution  of 
malicious  code.  To  continue  operating 
dependably,  then,  a  Web  service  must  be 
designed  and  implemented  so  that  it  is 
able  to  do  the  following: 

•  Recognize  and  resist  or  block  most 
attack  patterns  and  malicious  behaviors. 

•  Tolerate  and  safely  handle  the  errors 
and  failures  that  result  from  those 
attacks  and  malicious  behaviors  it  can¬ 
not  resist  or  block. 

•  Exhibit  resilience  by  isolating  and  con¬ 
straining  the  damage  and  recovering 
quickly  (to  an  acceptable  level  of  capa¬ 
bility)  from  successful  attacks  and 
malicious  behaviors. 


...  intentionally  hostile 
operating  conditions  are 
created  either  by  the 
presence  of  attack 
patterns  or  the 
behaviors  that  result 
from  execution  of 
malicious  code.^^ 

Furthermore,  to  be  deemed  trustwor¬ 
thy,  Web  service  software  must  not  only 
exhibit  the  properties  that  constitute 
dependability  and  security,  but  also  those 
that  constitute  assurability,  which  is  the 
ability  to  independently  verify  the  soft¬ 
ware’s  other  required  properties.  The 
properties  that  constitute  software 
dependability  are  correctness  and  pre¬ 
dictable  execution  (i.e.,  the  software  does 
what  it  is  supposed  to  do  and  nothing 
else),  and  in  some  cases  safety.  (Software 
safety  is  defined  in  the  National  Aeronau¬ 
tics  and  Space  Administration  Software 
Assurance  Glossary  <http://sw-assuran 
ce.gsfc.nasa.gov/help/glossary.php>  as 
the  systematic  identification,  analysis, 
tracking,  mitigation,  and  control  of  soft¬ 
ware  hazards  and  hazardous  functions, 
hazards  being  existing  or  potential  condi¬ 
tions  or  functions  that  can  contribute  to 
or  result  in  mishaps  or  accidents.  Software 
safety  does  not  concern  itself  with  pre¬ 
venting  intentionally  induced  incidents, 
even  though  such  an  incident  could  result 
in  a  mishap  or  accident.) 

The  properties  that  constitute  soft¬ 


ware  security  are  integrity  (inability  to  sub¬ 
vert)  and  availahiliy  (inability  to  sabotage), 
and  for  Web  services,  accountability  of  the 
service  as  a  non-human  actor  in  a  SOA 
(which  includes  non-repudiation  by  the  ser¬ 
vice  of  its  actions).  In  many  cases,  confi¬ 
dentiality  of  the  software  itself  is  also  a 
desirable  security  property:  The  software’s 
executable  and/or  operational  behaviors 
may  be  hidden  and/ or  obfuscated  to  make 
reconnaissance  and  disclosure  of  vulnera¬ 
bilities  difficult. 

The  properties  that  promote  assurabil¬ 
ity  include  the  following:  simplicity  (of 
design  and  implementation),  smallness  (of 
code),  and  traceability  (of  implementation 
to  requirements). 

In  practical  terms,  a  Web  service  can 
be  said  to  be  secure  when  it  achieves  the 
following: 

1.  The  behavior  of  the  service  itself 
(including  its  behavioral  state  changes 
in  response  to  inputs  and  external 
events)  does  not  make  the  service  vul¬ 
nerable  to  attack  or  malicious  code 
insertion/execution.  This  means  the 
service  must  handle  all  inputs  safely, 
validating  them  before  use  and  reject¬ 
ing  or  modifying  (to  make  acceptable) 
those  that  threaten  its  secure  behavior. 
It  also  means  that  the  service  must 
handle  errors,  exceptions,  faults,  and 
failures  safely  and  securely,  so  that 
these  events  do  not  cause  the  software 
to  enter  an  insecure  state  or  compro¬ 
mise  the  data  and  resources  to  which  it 
has  access. 

2.  The  service’s  interactions  and  inter¬ 
faces  must  be  secure.  This  includes 
those  used  among  the  service  soft¬ 
ware’s  constituent  components,  e.g., 
remote  procedure  calls,  and  those  used 
between  the  service  and  any  external 
entities,  including  other  Web  services 
(e.g.,  SOAP  over  HTTPS  with  WS- 
Security),  environment-level  compo¬ 
nents  (i.e.,  APIs,  call-level  interfaces), 
and  human  users  (i.e.,  user  interfaces). 

3.  The  service  is  executable  and  data  files 
in  the  file  system  must  be  protected 
from  unauthorized  access.  This  means 
that  the  configuration  parameters  of 
the  service  itself  and  of  its  execution 
environment  protections  must  be  as 
restrictive  as  possible. 

4.  The  service’s  attack  surface  must  be 
minimized.  If  this  has  not  been 
achieved  by  reducing  the  number  of 
vulnerabilities  in  the  service  itself 
(both  at  the  architectural  and  software 
levels),  it  might  be  achievable  through 
defense-in-depth  measures  that  mini¬ 
mize  the  exposure  of  the  vulnerabili¬ 
ties  that  were  not  eliminated. 
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Conclusion 

While  NIST’s  new  SP  800-95,  Gttide  to 
Secure  Web  Services^  should  prove  helpful  in 
increasing  Web  service  implementers’ 
knowledge  and  understanding  of  the 
security  standards  being  adopted  to  secure 
service-to- service  interactions  within  dis¬ 
tributed  SOA-based  information  systems, 
the  SP  does  not  discuss  methods  and 
techniques  for  design  and  implementation 
of  secure  Web  service  software.  This  leaves 
it  up  to  the  Web  service  developer  to  find 
that  type  of  information  elsewhere. 

A  good  place  for  developers  to  start 
looking  is  the  Department  of  Homeland 
Security’s  (DHS’)  BuildSecurityIn  Web 
portal  at  <https:/ /buildsecurityin.us-cert. 
gov/>.  The  resources  here  provide  a 
broad  range  of  recommendations  on  how 
Web  service  developers  can  add  security 
principles  and  practices  to  their  existing 
software  processes  so  that  the  software 
produced  by  those  processes  will  not  only 
perform  its  required  security  functions, 
but  will  exhibit  the  levels  of  attack-resis¬ 
tance,  attack-tolerance,  and  attack- 
resilience  required  to  minimize  its  attack 
surface  and  susceptibility  to  malicious 
code  penetrations  and  executions. 

Recently,  the  Defense  Information 
Systems  Agency  (DISA)  published  a 
Security  Technical  Implementation  Guide 
entitled  Application  Security  and  Devel¬ 
opment  Security.  This  can  be  downloaded 
at  <http:  /  /  iase.disa.mil/  stigs  /  stig/ asd 
-stig.pdf>.^ 
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Grace  A.  Lewis  and  Dr.  Dennis  B.  Smith 
Carnegie  Mellon  University,  Software  Engineering  Institute 

A.mong  current  technologies,  Service-Oriented  Architecture  (SOA)  has  the  greatest  potential  for  implementing  the  vision  of 
migration  to  net-centric  operations.  While  SOA  has  been  successful  in  many  cases,  it  has  also  been  marked  by  a  number  of 
expensive  failures.  This  article  outlines four  pillars  to  SOA  success  that  include  the  following:  developing  an  appropriate  SOA 
strategy,  implementing  effective  SOA  governance,  making  sound  technology  assessments,  and  accountingfor  the  fact  that  SOA 
requires  a  different  mindset.  As  a  result,  the  article  proposes  how  a  Department  of  Defense  (DoD)  organi^^ation  can  devel¬ 
op  and  implement  an  effective  strategy  for  SOA  implementation. 


A  cornerstone  of  DoD  policy  for 
future  software  and  systems  policy  is 
the  migration  of  systems  to  net-centric 
operations.  The  net-centric  vision  requires 
the  leveraging  of  a  highly  flexible  set  of 
capabilities  that  can  be  composed  quickly 
and  flexibly  into  applications  that  take 
advantage  of  the  interoperable  aspects  of 
the  web  and  provide  effective  mission 
value.  Among  current  technologies,  SOA 
has  the  greatest  potential  for  implement¬ 
ing  this  vision. 

However,  there  is  a  great  deal  of  con¬ 
fusion  about  what  SOA  is,  whether  it  is 
real,  and  what  it  takes  to  implement  a 
SOA-based  system.  This  article  provides  a 
high-level  introduction  to  SOA,  and  then 
outlines  how  a  DoD  organization  can 
develop  an  effective  strategy  for  imple¬ 
menting  the  vision. 

Basic  SOA  Concepts 

SOA  has  become  an  increasingly  popular 
mechanism  for  achieving  interoperability 
between  systems.  It  is  a  way  of  designing 
systems  composed  of  services  that  are 
invoked  in  a  standard  way.  Common  goals 
for  the  adoption  of  SOA  are  to  eliminate 
redundancy,  assemble  new  functionality 
from  existing  services,  adapt  systems  to 
changing  needs,  and  leverage  legacy 
investments.  An  SOA-based  system  is 
composed  of  the  following: 

•  Services:  These  are  reusable  compo¬ 
nents  that  represent  business  or  mis¬ 
sion  tasks,  such  as  customer  lookup, 
weather,  sensor  placement,  account 
lookup,  or  credit  card  validation. 
Services  can  be  globally  distributed 
across  organizations  and  reconfigured 
to  support  new  tasks  or  missions. 
They  are  reusable  because  they  can  be 
utilized  by  many  business  processes  or 
mission  threads.  They  usually  provide 
coarse-grained  functionality,  such  as 
customer  lookup  as  opposed  to  finer- 
grained  functionality  such  as  customer 
address  lookup. 

•  Service  consumers:  These  are  clients 


for  the  functionality  provided  by  the 
services,  such  as  end-user  applications, 
systems,  or  even  other  services. 

•  SOA  infrastructure:  The  infrastruc¬ 
ture  connects  service  consumers  to 
services.  It  usually  implements  a  loose¬ 
ly  coupled,  synchronous  or  asynchro¬ 
nous,  message-based  communication 
model,  but  other  mechanisms  are  pos¬ 
sible.  The  infrastructure  often  con¬ 
tains  elements  to  support  service  dis¬ 
covery,  security,  and  other  operations. 
A  common  SOA  infrastructure  is  an 
Enterprise  Service  Bus  (ESB)  to  sup¬ 
port  Web  Service  environments.  The 
Army’s  System  of  Systems  Common 
Operating  Environment  and  Defense 
Information  Systems  Agency’s  Net- 
Centric  Enterprise  Services  are  two 
examples  of  SOA  infrastructures 
within  DoD. 

The  benefits  of  SOA  can  be  signifi¬ 
cant.  However,  SOA  implementation  is  a 
complex  engineering  task  and  requires 
careful  attention  to  engineering  issues  as 
well  as  to  the  four  pillars  for  SOA  success 
that  are  presented  in  this  article. 

Pillars  for  Successful  SOA- 
Based  Systems  Development 

It  is  common  to  view  SOA-based  systems 
development  as  a  technical  problem  with 
a  technical  solution.  However,  successful 
SOA-based  systems  development  requires 
attention  to  four  piUars  as  illustrated  in 
Figure  1: 

•  Alignment  with  mission  and  business 
goals. 

•  Instantiation  of  principles  of  SOA 
governance. 

•  Evaluation  of  relevant  technologies 
for  SOA  implementation. 

•  Recognition  that  SOA  requires  a  dif¬ 
ferent  mindset  than  traditional  devel¬ 
opment. 

Strategic  Alignment 

The  first  pillar.  Strategic  Alignment,  focuses 
SOA  decision-making  on  mission  and 


business  priorities  rather  than  the  avail¬ 
ability  of  vendor  products,  or  preferences 
of  individuals  down  the  chain  of  com¬ 
mand.  If  the  wrong  strategy  is  selected,  it 
can  result  in  an  expensive  collection  of 
random  services  that  are  never  used.  A 
successful  SOA  strategy  includes  the  fol¬ 
lowing: 

•  Evidence  of  fulfillment  of  critical 
business  goals. 

•  Alignment  with  organizational  enter¬ 
prise  architecture  and  current  and 
future  Information  Technology  (IT) 
infrastructure. 

•  Realistic  choices  of  technologies  and 
infrastructures. 

•  Realistic  and  gradual  adoption  strate¬ 

gy* 

•  Adequate  SOA  governance  structure. 

•  Priorities  for  implementation. 

•  Reuse  strategy  across  internal  and 
external  organizations. 

These  issues  can  be  addressed  through 
activities  that  provide  a  focus  to  the  SOA 
implementation,  the  overall  business  plan, 
identification  of  high  priority  business 
processes,  and  disciplined  SOA  adoption. 

Focus  to  SOA  Implementation 

The  high-level  mission  and  business  goals 
need  to  dictate  the  focus  of  an  SOA 
implementation.  As  an  example,  four  dif¬ 
ferent  high-level  goals  can  lead  to  four 
different  SOA  strategies: 

•  An  SOA-based  system  to  support  a 
battlefield  will  have  critical  needs  to 
ensure  performance,  availability,  and 
security. 

•  Increasing  information  available  to 
stakeholders  will  focus  on  intuitive 
portals  and  creation  of  services  relat¬ 
ed  to  information  that  is  important  to 
stakeholders. 

•  Integrating  new  partners  will  focus  on 
a  flexible  SOA  infrastructure,  a  very 
well-described  service  repository,  and 
clear  guidelines  for  composition. 

•  Maximizing  security  may  lead  to  a  pro¬ 
prietary  SOA  infrastructure. 
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Overall  Business  Plan 

At  a  high  level,  there  is  recognition  that 
SOA  can  provide  agility,  adaptability, 
legacy  leverage,  and  integration  with 
business  partners.  Current  work  has  iden¬ 
tified  the  business  value  of  SOA  for  E- 
Commerce  [1],  E-Services,  banking,  and 
on-line  services.  In  order  to  determine 
the  amount  of  investment  required  and 
the  projected  payoff,  an  economic  analy¬ 
sis  needs  to  be  planned  at  the  beginning 
of  an  SOA  implementation  to  identify 
the  following: 

•  What  constitutes  a  success  within  the 
context  of  a  specific  SOA  implemen¬ 
tation? 

•  How  is  return  on  investment  mea¬ 
sured? 

•  What  are  the  resulting  savings  of  SOA 
implementation  (e.g.  infrastructure 
consolidation,  server  and  application 
virtualization,  reuse  of  services,  busi¬ 
ness  agility)? 

Identification  of  High  Priority 
Business  Processes 

Any  organization  has  many  potential  busi¬ 
ness  process  tasks  that  are  candidates  for 
services.  Services  are  identified  through  a 
top-down  analysis  of  business  and  mis¬ 
sion  processes,  a  bottom-up  legacy  system 
inventory,  or  a  combination  of  the  two. 
High-priority  services  are  selected  based 
on  their  relationship  to  critical  goals. 
Traditional  business  process  modeling, 
business  process  analysis,  and  business 
process  reengineering  techniques  can  help 
to  model  business  processes  and  identify 
areas  where  services  may  be  valuable. 
Although  these  methods  will  not  model 
services,  they  suggest  a  starting  point  for 
setting  priorities.  Some  of  these  approach¬ 
es  include  the  following: 

•  Enterprise  architecture  —  analyzes  bus¬ 
iness  goals,  what  the  business  does,  the 
type  of  information  needed,  and  how 
the  business  uses  IT  to  meet  its  goals. 

•  Business  process  analysis  -  models  the 
business  and  its  relationship  to  the 
external  environment.  This  is  an 
approach  for  identifying  business 
processes  that  are  candidates  to 
become  services. 

•  Business  process  modeling  -  analyzes 
and  optimizes  business  processes  to 
optimize  current  performance.  This 
can  provide  details  on  the  modeling  of 
specific  processes  once  they  have  been 
identified  as  candidates. 

•  Business  process  reengineering  —  ana¬ 
lyzes  current  business  processes  and 
changes  these  processes,  often  in  a 
radical  way,  to  meet  new  business 
needs. 


Disciplined  SOA  Adoption 

An  SOA  implementation  can  start  with  a 
big  hang  approach  that  attempts  to  get  SOA 
implemented  at  once  throughout  an  enter¬ 
prise.  However,  it  is  more  prudent  to 
begin  with  a  pilot  project  that  will  provide 
a  proof  of  concept.  Pilot  projects  should 
focus  on  areas  that  provide  high  impact 
and  visibility  with  the  lowest  risk.  Gradual 
implementation  can  then  lead  to  other 
projects  that  integrate  a  single  organiza¬ 
tional  unit,  to  projects  that  integrate  mul¬ 
tiple  business  units,  and  later  to  large  scale 
efforts  that  provide  a  virtual  enterprise 
where  ah  applications  are  built  based  on 
services  [2]. 

SOA  Governance 

Governance  has  been  rated  as  the  main 
inhibitor  of  SOA  adoption  [3].  SOA  gover¬ 
nance  provides  a  set  of  policies,  rules,  and 
enforcement  mechanisms  for  developing, 
using,  and  evolving  SOA-based  systems, 
and  for  analysis  of  their  business  value. 
SOA  governance  includes  policies,  proce¬ 
dures,  roles,  and  responsibilities  for  design¬ 
time  governance  and  runtime  governance. 

Design-time  governance  includes  ele¬ 
ments  such  as  rules  for  strategic  identifica¬ 
tion  of  services,  development,  and  deploy¬ 
ment  of  services,  reuse,  and  legacy  system 
migration  to  services.  It  also  enforces  con¬ 
sistency  in  use  of  standards,  SOA  infra¬ 
structure,  and  processes. 

Runtime  governance  develops  and 
enforces  rules  to  ensure  that  services  are 
executed  only  in  ways  that  are  legal. 
Runtime  governance  procedures  address 
concerns  such  as  1)  access  to  applications 
and  data,  2)  the  replacement  of  services, 
and  3)  consistent  interactions  with  the  SOA 


infrastructure. 

Service-level  agreements  (SLAs)  also 
fall  under  runtime  governance.  SLAs  can 
include  runtime  validation  of  contractual 
specifications  on  performance,  throughput, 
and  availability;  the  use  of  automated  met¬ 
rics  for  tracking  and  reporting;  and  prob¬ 
lem  management. 

A  well-defined  governance  model 
needs  to  answer  such  questions  as  the  fol¬ 
lowing: 

•  What  is  the  process  for  determining 
what  services  to  create? 

•  What  is  the  process  for  evolving  and 
changing  services  if  there  are  many 
consumers  of  the  service? 

•  Many  services  can  be  common  across 
several  lines  of  business  in  an  enter¬ 
prise.  Who  owns  these  common  ser¬ 
vices? 

•  Who  owns  the  actual  data  if  more  than 
one  service  is  using  it? 

•  What  is  the  resolution  mechanism  if 
there  are  conflicting  requirements  or 
change  requests  for  shared  services? 

•  What  happens  if  the  same  (or  similar) 
service  is  being  developed  by  more  than 
one  service  provider? 

•  What  mechanisms,  tools  and  policies 
are  used  for  maintaining  and  monitor¬ 
ing  deployed  services? 

•  How  are  enterprise-wide  policies 
enforced  across  various  services  both 
internally  as  well  as  externally  to  the 
organization? 

•  Who  owns  and  maintains  the  shared 
repository  of  services  in  an  organiza¬ 
tion? 

•  How  are  SLAs  defined  and  enforced 
between  service  consumers  and 
providers? 


Figure  1:  Pillars  of  SQA-Based  Systems  JPevelopment 
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Figure  2:  T-Checks  Approach  for  Technology 
Evaluation 


Technology  Evaluation 

Because  an  SOA  implementation  may  use 
a  number  of  technologies  in  novel  con¬ 
texts,  it  is  important  to  evaluate  whether  a 
specific  set  of  technologies  is  appropriate 
for  the  task  at  hand.  Pillar  3  requires  deter¬ 
mining  the  fitness  of  a  technology  within 
a  specific  context  before  making  a  long 
term  commitment  to  it.  In  adopting  an 
SOA-based  systems  approach,  a  number 
of  different  technologies,  standards  and 
tools  may  be  part  of  an  implementation. 
Examples  of  these  different  technologies 
can  involve  specific  web  service  standards, 
versions  and  tool  implementations,  cus¬ 


tom  infrastructures,  ESBs,  interfaces  to 
specific  databases,  and  language  bindings. 

It  is  easy  to  draw  a  slide  showing  how 
the  pieces  can  fit  together  at  an  abstract 
level.  However,  ah  technologies  work  well 
within  a  specific  context  and  under  certain 
conditions.  For  example,  Web  services 
work  well  for  asynchronous  communica¬ 
tion  over  the  Internet.  In  a  business  envi¬ 
ronment  these  conditions  are  very  com¬ 
mon,  but  in  a  military  tactical  command 
and  control  environment  this  might  not 
be  the  case  because  of  high  performance 
and  availability  requirements. 

One  way  to  perform  this  type  of 
analysis  is  through  a  light  weight  evalua¬ 
tion  method  such  as  T-Checks  [4,  5], 
Other  approaches  can  be  used;  however, 
the  approach  should  enable  a  hands-on 
contextual  analysis.  The  T-Checks 
approach  is  illustrated  in  Figure  2  and  can 
be  summarized  in  terms  of  the  following 
steps: 

•  Identify  technology  requirements  and 
context.  Determine  and  document 
why  the  organization  wishes  to  con¬ 
duct  the  evaluation,  what  the  expecta¬ 
tions  and  concerns  are  with  respect  to 
the  technology  capabilities,  and  what  is 
the  context  in  which  the  technology 
plans  on  being  used.  Determine  the 
environment  in  which  the  evaluation 
will  take  place,  including  expectations 
and  constraints  of  the  technology  and 
measures  of  success. 

•  Develop  hypotheses  that  are  derived 
from  the  expectations  placed  on  the 
technology.  Hypotheses  are  claims 
about  the  technologies  that  are  to  be 
sustained  or  refuted. 

•  Develop  criteria  to  determine  if  the 
results  sustain  or  refute  a  hypothesis. 
Criteria  are  stated  as  a  clearly  measur¬ 
able  statement  of  capability.  Each 
hypothesis  can  have  one  or  more  crite¬ 
ria,  depending  on  the  breadth  covered 
by  the  hypothesis. 

•  Design  and  implement  the  experimen¬ 
tal  solution  which  is  the  simplest  set  of 
applications  and/or  components  that 
are  able  to  answer  the  questions  posed 


by  the  hypotheses  and  associated  crite¬ 
ria,  within  a  given  scenario.  The  exper¬ 
imental  solution  is  implemented,  run, 
and  observed,  until  there  is  enough 
information  to  sustain  or  refute  the  set 
of  hypotheses. 

•  Evaluate  the  solution  against  criteria  in 
order  to  make  a  decision  with  respect 
to  the  fitness  of  the  technology  for  the 
context  in  which  it  is  intended  to  be 
used.  Based  on  the  results  of  the  eval¬ 
uation  there  should  be  enough  infor¬ 
mation  to  decide  if  it  is  the  following: 
°  A  good  fit  with  requirements. 

°  Not  a  good  fit  with  requirements. 

°  Has  some  mismatches  that  could 
potentially  be  solved  by  modifying 
the  context  or  modifying  the  tech¬ 
nology  itself 

Awareness  of  a  Different 
Mindset 

There  are  a  unique  set  of  challenges  in 
building  SOA-based  systems.  These  chal¬ 
lenges  require  a  different  development 
approach  that  deals  with  the  characteris¬ 
tics  of  SOA-based  systems.  Although  it  is 
difficult  to  generalize,  some  of  the  con¬ 
trasts  of  SOA  systems  versus  traditional 
systems  are  presented  in  Table  1. 

These  differences  impact  the  way  soft¬ 
ware  is  developed  throughout  the  life 
cycle: 

•  During  requirements,  it  is  important  to 
have  close  ties  to  business  process 
modeling  and  analysis.  In  addition, 
there  is  the  need  to  anticipate  potential 
service  requirements  from  unknown 
consumers. 

•  During  architecture  and  design,  it  is 
important  to  have  technology  evalua¬ 
tions  and  to  perform  explicit  trade-off 
analyses. 

•  Implementation  decisions  will  be 
impacted  by  emerging  standards  and 
may  require  simulation  of  the  deploy¬ 
ment  environment. 

•  Testing  requires  a  strong  emphasis  on 
exception  handling  and  requires  all  test 
instances  of  services  are  available. 

•  Maintenance  requires  more  sophisti¬ 
cated  impact  analyses  and  greater 
coordination  of  release  cycles. 

Because  SOA  implementation  requires 

a  different  mindset  than  traditional  soft¬ 
ware  development  and  acquisition,  it  is 
important  to  develop  an  overall  transition 
strategy  to  address  how  to  acquire  the  new 
skills  that  may  be  required  through  train¬ 
ing  personnel,  hiring  new  staff,  or  bringing 
in  external  experts.  In  addition  SOA 
merges  the  technical  and  business  worlds; 
therefore,  it  is  important  to  have  expertise 


Table  1:  Some  Differences  Between  Traditional  Systems  Development  and  SOA-Based  Systems 
Development 


Traditional  Systems  Development 

SOA-Based  Systems  Development 

Tight  coupling  between  system 
components 

Loose  coupling  between  applications  and 
services 

Shared  semantics  at  design  time 

Semantics  ideally  enable  dynamic 
discovery  and  execution  of  services 

Known  set  of  users  and  usage  patterns 

Potentially  unknown  service  users  and 
usage  patterns 

System  components  all  within  the  same 
organization 

Multiple  organizations  providing  and 
supporting  system  components 
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in  both  fields.  The  fact  that  SOA  imple¬ 
mentations  have  the  potential  of  crossing 
the  enterprise  also  suggests  the  need  for 
developing  a  perspective  that  spans  the 
concerns  of  the  entire  enterprise,  rather 
than  just  the  issues  of  a  specific  program 
or  business  unit.  As  discussed  in  the  sec¬ 
tion  Disciplined  SOA  Adoption,  a  gradual 
adoption  process  that  starts  with  small 
scale  pilots  and  expands  gradually  is  also 
recommended. 

Conclusions 

The  SOA  approach  offers  real  value  for 
DoD  organizations  as  a  technology  for 
migrating  toward  net-centric  operations. 
However,  the  rhetoric  surrounding  SOA 
can  often  be  confusing  and  misleading. 
Establishing  an  effective  SOA  approach  is 
a  complex  acquisition,  management  and 
technical  task.  It  requires  the  following: 

•  Alignment  with  mission  and  business 
goals. 

•  Instantiation  of  principles  of  SOA 
governance. 

•  Evaluation  of  relevant  technologies 


for  SOA  implementation. 

•  Recognition  that  SOA  requires  a  dif¬ 
ferent  mindset  than  traditional  devel¬ 
opment.  ♦ 

References 

1.  Tilley,  S.,  et  al.  ‘'On  the  Business  Value 
and  Technical  Challenges  of  Adopting 
Web  Services.”  Journal  of  Software 
Maintenance  and  Evolution  16  (2004): 
16,31-50. 

2.  Schulte,  R.  “Meeting  the  Challenges  of 
SOA  Adoption.”  SOA  in  Action 
Virtual  Conference,  Nov.  2006. 

“SOA  Trend  Survey.”  InfoWorld  2006. 
Lewis,  G.,  and  L.  Wrage.  “A  Process 
for  Context-Based  Technology  Eval¬ 
uation.”  Technical  Note  CMU/SEI- 
2005-TN-025.  CMU/SEI,  2005. 

Lewis,  G.,  and  L.  Wrage.  “Model  Prob¬ 
lems  in  Technologies  for  Interopera¬ 
bility:  Web  Services.”  Technical  Note 
CMU/SEI-2006-TN-021.  CMU/SEI, 
2006. 


About  the  Authors 


Grace  A.  Lewis  is  a  senior 
member  of  the  technical 
staff  at  SEI.  She  is  cur¬ 
rently  the  lead  for  the 
System  of  Systems  Engi¬ 
neering  team  within  the 
Intermediate  Systems  to  Intermediate 
Systems  initiative.  Lewis’  current  inter¬ 
ests  and  projects  are  in  SOA,  legacy  sys¬ 
tem  modernization,  and  software  devel¬ 
opment  life-cycle  activities  in  systems  of 
systems.  She  has  a  bachelor’s  degree  in 
systems  engineering  and  an  executive 
masters  of  business  administration  from 


Icesi  University  in  Cali,  Colombia,  as 
well  as  a  master’s  degree  in  software 
engineering  from  CMU 


SEI 

4500  Fifth  AVE 
Pittsburgh,  PA  15213 
Phone:  (412)  268-5851 
Fax:  (412)  268-5758 
E-mail:  glewis@sei.cmu.edu 


Dennis  B.  Smith,  Ph.D., 

is  a  senior  member  of  the 
technical  staff  and  is  lead 
of  the  Integration  of 
Software-Intensive  Sys¬ 
tems  initiative  at  the  SEI. 
This  initiative  focuses  on  developing  and 
applying  methods,  tools,  and  technolo¬ 
gies  that  enhance  the  effectiveness  of 
complex  networked  systems  and  systems 
of  systems.  Smith  has  been  involved  with 
working  with  DoD  organizations  in 
developing  an  SOA  capability,  including 
issues  of  SOA  strategy,  governance  and 
migration  of  legacy  assets  to  SOA.  He 
was  the  co-editor  of  the  Institute  of 
Electrical  and  Electronics  Engineers  and 
International  Organization  for  Standar¬ 
dization-recommended  practice  on 
Computer-Aided  Software  Engineering 
Adoption,  and  has  been  general  chair  of 
two  international  conferences.  Smith 
holds  a  masters  degree  and  doctorate 
from  Princeton  University,  and  a  bache¬ 
lor’s  degree  from  Columbia  University. 


SEI 

4500  Fifth  AVE 
Pittsburgh,  PA  15213 
Phone:  (412)  268-6850 
Fax:  (412)  268-5758 
E-mail:  dbs@sei.cmu.edu 


Get  Your  Free  Subscription 


Fill  out  and  send  us  this  form. 

517  SMXS/MXDEA 
6022  Fir  Ave 
Bldg  1238 

Hill  AFB,  UT  84056-5820 
Fax:  (801)  777-8069  DSN:  777-8069 
Phone:  (801)  775-5555  DSN:  775-5555 

Or  request  online  at  www.stsc.hill.af.nnil 

Name: _ 

Rank/Grade: _ 

Position/T  itle: _ 

Organization: _ 

Address: _ 


I  Base/City: _ I 

^  State: _ Zip: _ * 

I  Phone:  ( _ ) _ I 

!  Fax:( _ ) _ ! 

I  E-mail: _ I 

I  Check  Box(es)  To  Request  Back  Issues:  | 

I  May2006  Q  Transforming  I 

^  June2006  n  Why  Projects  Fail  * 

I  July2006  n  Net-Centricity  . 

I  Aug2006  n  Ada  2005  I 

I  Sept2006  n  Software  Assurance  I 

^  Oct2006  n  Star  Wars  TO  Star  Trek  * 

I  Nov2006  n  Management  Basics  . 

I  Dec2006  n  Requirements  Eng.  I 

I  Jan2007  Q  Publisher’s  Choice  I 

■  Feb2007  n  CMMI  ' 

I  Mar2007  Q  Software  Security  - 

I  Apr2007  Q  Agile  Development  I 

I  May2007  Q  Software  Acquisition  I 

*  June2007  n  COTS  Integration  * 

I  July2007  n  Net-Centricity  - 

I  Aug2007  n  Stories  OF  Change  I 

I  To  Request  Back  Issues  ON  Topics  Nor  | 

I  Listed  Above,  Please  Contact  <stsc.  i 

I  CUSTOMERSERVICE@HILL.AF.MIL>.  | 


September  2007 


www.stsc.hill.af.mil  I  3 


Defining  Services  Using  the  Warfighter’s  Language 


Michael  S.  Russell 
General  Dynamics  Information  Technology 

Warfighters  establish  relationships  with  other  wa  fighters  to  exchange  information  and  accomplish  their  mission.  Net-centricity 
and  other  information  service  concepts  provide  a  means,  hut  to  a  wa  fighter  these  are just  technical  solutions  to  the  operators  need. 

The  missing  piece  in  the  push  towards  service  oriented  approaches  is  an  understanding  of  what  wa  fighters  expect from  a  service 
and  a  means  to  capture  these  expectations  as  part  of  the  joint  Capabilities  Integration  and  Development  System  (JCIDS). 


Service-Oriented  Architectures  (SOA), 
and  services  in  general,  are  a  trouble¬ 
some  subject  for  many  warfighters. 
Warfighters  understand  what  informa¬ 
tion  they  need  to  execute  a  mission,  and 
they  are  comfortable  defining  informa¬ 
tion  requirements  through  JCIDS  docu¬ 
ments  and  supporting  architectures. 
However,  when  this  information  is  pro¬ 
vided  by  a  service,  especially  when 
depicted  as  a  cloud  labeled  Global 
Information  Grid  (GIG),  this  comfort  level 
goes  down. 

Defining  a  service  from  a  technical 
perspective  is  not  hard.  According  to  the 
World  Wide  Web  Consortium  [1],  a  ser¬ 
vice  is  a  software  system  designed  to  sup¬ 
port  interoperable  machine-to-machine 
interaction  over  a  network.  Services  are 
standards-based  and  may  contain  the 
business  logic  needed  to  turn  raw  data 
into  information. 

This  definition  is  fine  for  the  engi¬ 
neers,  but  really  does  nothing  to  help 
warfighters  specify  what  information 
they  need  from  the  service,  when  they 
need  it,  and  how  they  can  trust  that  the 
service  —  which  they  do  not  control  —  will 
provide  them  accurate  and  timely  infor¬ 
mation.  Additionally,  the  warfighter  may 
not  have  visibility  into,  or  control  over, 
the  business  rules  used  to  derive  this 
information  from  raw  data. 

The  issue  with  services  is  fundamen¬ 
tally  one  of  perception.  The  average  per¬ 
son  typically  goes  to  a  Web  site  known  to 
be  trustworthy,  one  that  provides  timely 
and  accurate  information.  Warfighters  do 
the  same  thing;  they  get  information 
from  a  trustworthy  source,  normally  a 
higher  echelon  that  they  know  provides 


authoritative,  timely,  and  accurate  infor¬ 
mation.  The  services  paradigm  can  break 
this  approach  by  obscuring  the  source  of 
information  (and  how  that  information 
was  derived)  from  the  warfighter. 

When  services  are  implemented  in  a 
way  that  mimics  traditional  lines  of  com¬ 
munication,  nothing  changes  from  the 
warfighter’s  perspective.  They  are  still 
receiving  the  same  information  from  the 
same  sources.  However,  this  approach 

'*An  optimal  services 
implementation  allows 
the  warfighter  to  specify 
the  needed  information, 
when  it  is  needed,  the 
quality  of  the 
information,  and  an 
objective  way  to 
determine  the 
trustworthiness  of  the 
information.^* 

limits  the  benefits  of  a  true  services-ori- 
ented  approach  since  it  just  replaces  one 
communications  technology  for  another 
without  changing  how  information  is 
discovered  and  delivered. 

An  optimal  services  implementation 


allows  the  warfighter  to  specify  the  need¬ 
ed  information,  when  it  is  needed,  the 
quality  of  the  information,  and  an  objec¬ 
tive  way  to  determine  the  trustworthiness 
of  the  information.  This  allows  the  sys¬ 
tem  supporting  the  warfighter  to  search 
the  GIG  and  other  networks  for  an  avail¬ 
able  information  source  that  provides 
that  information,  to  establish  a  connec¬ 
tion,  and  to  start  providing  information. 
This  optimal  implementation  will  also 
enable  the  warfighter  to  specify,  or  at 
least  have  insight  into,  the  business  rules 
used  to  generate  the  information. 

However,  this  implementation  often 
requires  the  warfighter  to  accept  that  for¬ 
malized  information  flow  between  com¬ 
mand  echelons,  such  as  the  flow  of  logis¬ 
tics  information  from  superior  to  subor¬ 
dinate,  may  no  longer  exist.  TelHng  a 
warfighter  that  his  subordinates  will 
receive  information  directly  from  a  ser¬ 
vice  outside  of  the  chain  of  command 
may  fit  reality,  but  it  may  not  fit  doctrine 
or  a  warfighter’s  perception  about  how 
information  should  flow. 

Defining  Services  for  the 
Warfighter 

Warfighters  tend  to  think  very  directly:  I 
need  to  know  tomorrow's  weather  forecast.  The 
weather  service  provides  forecasts,  so  I  will  call  it 
and  get  tomorrow’s  forecast.  The  warfighter 
could  describe  this  need  architecturally, 
as  shown  in  Figure  1 .  In  the  example,  the 
unit’s  commander  knows  that  the  same 
weather  service  is  habitually  attached  to 
his  unit  and  knows  it  will  provide  accu¬ 
rate  and  timely  information.  He  will  also 
have  visibility  into  the  business  rules 
used  to  derive  the  information  he  needs 
from  raw  data. 

Figure  2  shows  a  non- services  imple¬ 
mentation  of  this  requirement.  The  net¬ 
work  device  could  be  a  local  area  net¬ 
work,  a  radio,  or  another  communica¬ 
tions  device. 

A  services  approach  could  be  used  to 
implement  the  same  technical  require¬ 
ment.  In  Figure  3,  the  technical  solution 


Figure  1 :  How  the  Wa  fighter  Describes  a  Need 

Command  Weather  Forecast  Weather 

Post  Section 
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has  implemented  a  services  approach  but 
from  the  warfighter’s  perspective,  noth¬ 
ing  has  changed.  The  same  information 
is  flowing  from  the  same  source.  This 
approach  is  similar  to  how  selected  ser¬ 
vices,  such  as  address  books,  are  current¬ 
ly  provided. 

Figure  4  depicts  a  common  technical 
implementation  that  allocates  the  weath¬ 
er  information  requirement  to  a  GIG 
service,  as  opposed  to  a  habitually  asso¬ 
ciated  weather  section.  Several  different 
weather  information  providers  could 
conceivably  meet  the  warfighter’s  infor¬ 
mation  need.  This  depiction,  even  if 
technically  correct,  does  not  tell  the 
warfighter  who  wiU  be  providing  the 
information,  only  that  someone  will  pro¬ 
vide  it. 

Figure  4  highlights  the  issue  many 
warfighters  have  with  services.  While  the 
services  themselves  are  invisible  to  the 
warfighter,  the  information  provided  by 
them  is  not.  The  issue  from  the  warfight¬ 
er’s  perspective  is  not  about  the  services 
themselves,  but  rather  the  concept  of 
who  owns  the  information,  how  that 
information  flows,  and  what  rules  were 
used  to  derive  that  information.  This 
issue  readily  becomes  apparent  when  a 
services  approach  is  implemented  in 
such  a  way  as  to  break  traditional  com¬ 
mand  and  unit  relationships. 

This  approach  has  operational  bene¬ 
fits:  a  deploying  unit  may  no  longer  need 
an  associated  weather  section,  weather 
information  can  be  pulled  from  a  wider 
variety  of  weather  sources,  and  constant 
weather  information  can  be  sent  to  aU 
units  within  a  geographic  region.  There 
are,  however,  downsides  including  quali¬ 
ty  of  service,  the  loss  of  connection  to  a 
local  information  source,  the  need  to 
quantify  information  trustworthiness, 
and  the  rules  used  to  derive  the  data. 

To  mitigate  these  downsides, 
warfighters  should  have  more  control 
over  the  requirements  process  that  spec¬ 
ifies  how  services  will  be  implemented. 
This  includes  being  able  to  specify  an 
organization  that  provides  trusted  infor¬ 
mation  and  the  business  rules  that  orga¬ 
nizations  use  to  generate  the  warfighter’s 
mission  critical  data. 

Requirements  Development 

Warfighters  are  responsible  for  defining 
information  requirements  by  specifying 
who  exchanges  what  information,  with 
whom  it  is  exchanged,  why  the  informa¬ 
tion  is  necessary,  how  the  information  is 
derived,  and  how  the  information 
exchange  must  occur  [2].  Typically,  these 
information  requirements  revolve 


Figure  2:  Technical  Implementation 

around  the  following: 

•  Describing  the  required  information. 

•  Identifying  the  information  producer 
and  consumer. 

•  Describing  operational  performance, 
security,  and  information  assurance 
attributes. 

•  Detailing  the  business  process, 
including  operational  activities 
and/or  triggers  that  initiate  informa¬ 
tion  transfer. 


Describing  how  one  operational  unit 
sends  information  to  another  operational 
unit  is  straightforward.  Using  the  weather 
forecast  example,  the  weather  section 
exchanges  weather  information  with  the 
command  post  upon  request,  the  informa¬ 
tion  is  needed  for  mission  planning,  and 
the  information  is  unclassified  but  must 
be  securely  and  accurately  delivered. 

Continued  on  Page  18 


Figure  3:  Service-Enabled  Technical  Implementation 
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Systems  and  Software  Technology  Conference  2007: 

Enabling  the  Global  Mission 


The  Systems  and  Software  Technology  Conference  (SSTC) 
held  June  18-20  in  Tampa,  Florida  focused  its  attendee’s 
attention  on  the  theme  of  Enabling  the  Global  Mission,  striving  to 
create  and  perfect  the  way  military  and  industry  professionals 
enable  the  warfighter  by  providing  improved,  accessible  capa¬ 
bilities.  Partnering  with  U.S.  Central  Command,  the  conference 
planners  sought  to  emphasize  and  answer  the  needs  of  the 
warfighters  by  creating  a  collaborative  and  educational  environ¬ 
ment  to  explore  proven  best  practices  and  share  successful 
insights.  In  2007,  the  SSTC  departed  from 
Salt  Lake  City  after  18  successful  years  and 
landed  on  the  Tampa  Bay  shores. 

The  central  theme  of  Enabling  the 
Global  Mission  streamed  throughout  the 
conference,  facilitating  open  discussion 
among  military  and  professionals  to  not 
only  recognize  the  needs  of  the  warfighter 
but  to  also  address  them.  The  SSTC  con¬ 
ference  continued  its  lifelong  goal  of  cre¬ 
ating  an  open  environment  to  achieve 
results. 

In  his  opening  general  session,  keynote 
speaker  Major  General  Timothy  F. 

Ghormley,  Chief  of  Staff,  U.S.  Central 
Command,  presented  attendees  with  a 
unique  view  of  how  software  intensive  sys¬ 
tems  are  making  a  difference  in  our 
nation’s  defense,  while  integrating  the 
needs  of  the  warfighter  through  their  per¬ 
spective  in  the  field.  Ghormley  challenged 
the  audience  to  assist  in  developing  ways 
to  render  improvised  explosive  devices 
ineffective  and  emphasized  the  urgency  of 
this  need.  Ghormley  repeated,  “Any 
Network,  Any  Device”  to  enunciate  the 
impending  necessity  of  ease  of  communi¬ 
cation. 

Throughout  the  four- day  event,  gov¬ 
ernment  and  industry  leaders  enlightened 
their  audiences  with  solutions  to  important 
issues,  such  as  focusing  on  system  engi¬ 
neering  problems  early  in  product  devel¬ 
opment  and  the  need  to  find  better  ways  to 
analyze  computer  code.  Chris  Miller  presented  an  outstanding 
discussion  of  how  we  are  living  in  exponential  times.  Jim  Tucker 
expounded  upon  the  horrific  events  of  the  attempted  aircraft 
hijacking  of  Fed  Ex  flight  705,  which  he  endured.  The  previous 
examples  are  a  microcosm  of  the  depth  and  spectrum  of 
knowledge  shared  at  SSTC  2007. 

From  the  more  than  120  presentations,  attendees  were  able 
to  delve  into  the  topics  of  rapid  response  capabilities,  robust 


engineering,  systems  assurance,  technology  futures,  communi¬ 
cation  infrastructure,  and  enablement  of  the  workforce. 
Numerous  insights  were  provided  from  projects  and  organiza¬ 
tions,  showing  and  educating  on  the  success  in  their  efforts. 
Common  discussions  within  many  of  these  presentations  out¬ 
lined  varying  perspectives  on  vulnerabilities  and  threats  to  soft¬ 
ware  systems  and  countermeasures  for  them.  Surprisingly  we 
learned  that  real-time  JAVA  extensions  are  making  the  language 
an  acceptable  tool  for  real-time  software  development. 

Attendees  also  discovered  how  they  can 
use  the  newly  released  update  to  the 
Capability  Maturity  Model  (Vers.  1.2)  to 
improve  their  development  processes. 

In  addition  to  presentations  and  tuto¬ 
rials,  attendees  also  had  the  opportunity  to 
participate  in  a  panel  discussion  with  gov¬ 
ernment  and  industry  leaders,  providing 
questions  and  receiving  answers  that 
expressed  the  different  perspectives  from 
these  two  sides.  This  year’s  discussion 
sparked  quite  a  lively  debate  between  the 
panelists. 

As  has  come  to  be  expected  with 
SSTC,  participants  were  pampered  with 
great  food,  key  information,  networking, 
and  a  fun  evening  cruising  around  Tampa 
Bay.  Speaking  of  fun,  attendees  of  this 
year’s  SSTC  trade  show  were  able  to  gain 
a  sense  of  what  it  is  like  to  fly  though  the 
Grand  Canyon  at  near  supersonic  speeds 
in  an  actual  flight  simulator. 

To  sum  up  the  SSTC  experience,  one 
appreciative  and  excited  attendee  noted,  “I 
appreciated  the  real-world  case  studies 
provided  by  speakers  and  I  received  great 
information  from  a  subject  matter  expert 
who  has  done  it.”  Some  of  our  other 
favorite  quotes  included,  “Good  social 
activities  and  opportunities  to  network,” 
and  “Great  conference.”  Another 
attendee  said,  “I’m  only  allowed  to  attend 
one  conference  a  year  and  SSTC  is  always 
the  one  I  attend.” 

Although  SSTC  amended  many  traditions,  it  remains  dedi¬ 
cated  to  preserving  what  makes  SSTC  the  premier  technology 
event  for  the  Department  of  Defense  by  providing  a  showcase 
for  the  cutting-edge  technologies.  SSTC  aims  to  create  a  collab¬ 
orated  environment  to  Enabling  the  Global  Mission  and  serv¬ 
ing  the  warfighter’s  need  for  ease  of  information. 

Photo  credits:  Brent  Baxter  and  Nicole  Kentta 
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attend  one  conference  a 
year  and  SSTC  is  always 
the  one  I  attend.  ” 
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Session  attendees 
and  speakers 
mingle  before 
their  morning 
presentations. 


Attendees  and  guests  board  the  yacht.  Starship,  for  the  conference's  special  dinner 
cruise  event. 
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the  trade  show. 
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Nicole  Kentta  and  Glen  Guke  greet  trade-show  attendees  as  they 
stop  at  the  SSTC  booth. 


Barry  Boehm,  Jo  Ann  Gane,  Mike  Phillips,  and  Rick  Turner  discuss  new  article 
ideas  at  the  annual  CROSSTALK  author  luncheon. 


Conference  attendees  take  a  break  to  mingle  and  enjoy  the 
fabulous  food. 


Service-Oriented  Architectures 


Continued  From  Page  15 

However,  when  this  same  scenario  is 
detailed  using  the  services  implementa¬ 
tion  in  Figure  4,  the  information  pro¬ 
ducer  cannot  always  be  defined.  The 
information  producer  could  be  one  of 
many  weather  information  producers 
located  in  the  deployed  theater,  at  a 
stateside-based  location,  or  any  point  in 
between.  Instead  of  describing  the 
expected  point-to-point  information 
exchange,  the  warfighter  now  sees  a 
request  sent  to  a  service.  This  can  leave 
the  warfighter  feeling  he  has  lost  control 
of  where  he  receives  his  information 
and  with  doubts  of  the  trustworthiness 
of  the  information. 

Mitigating  these  concerns  requires 
changes  to  the  way  operationally  related 
architecture  data  is  documented.  First, 
change  the  way  architectural  diagrams 
are  designed,  highlighting  the  fact  that 
an  information  service  is  provided  by  an 
organization,  not  a  computer. 
Warfighters  build  trust  with  other 
warfighters,  not  the  technology  which 
provides  information.  Fundamentally, 
services  are  just  the  way  an  organization 
—  no  matter  where  in  the  world  it  is 
located  —  can  provide  information  to  the 
warfighter. 

Second,  requirements  developers 
should  add  additional  information  to  the 
warfighter’s  information  exchange 
matrix  (information  concerning  quality, 
trustworthiness,  etc.)  and  to  the 
warfighter’s  list  of  Information 


Exchange  Requirements.  For  example, 
trusted  operational  sources  for  informa¬ 
tion  could  be  added  as  well  as  the 
warfighter’s  expectations  for  graceful 
information  degradation  on  limited 
bandwidth  networks. 

Third,  the  warfighter  is  concerned 
about  how  raw  data  is  captured,  validat¬ 
ed,  and  used  to  develop  information.  In 
today’s  rapid-paced  environment,  the 
warfighter  does  not  have  time  to  study 
raw  data  to  derive  the  information  need¬ 
ed  to  make  effective  decisions.  However, 
making  decisions  based  on  information 
derived  to  support  someone  else’s  busi¬ 
ness  process  may  lead  to  a  bad  decision. 
So  the  warfighter  must  be  able  to  help 
specify  the  processes  used  to  develop 
the  information,  or  at  least  be  able  to 
have  some  visibility  into  the  process. 

Capturing  the  Warfighter^s 

Service-Related 

Requirements 

From  the  warfighter’s  perspective,  infor¬ 
mation  is  being  exchanged  from  one 
organization  to  another.  From  this  per¬ 
spective,  services  are  the  technical 
implementation  —  not  the  operational 
requirement.  A  diagram  such  as  Figure 
5,  while  it  still  includes  the  GIG,  clearly 
identifies  to  the  warfighter  where  he  can 
get  his  weather  forecast  and,  to  some 
extent,  an  expectation  about  the  quality 
of  data  that  will  be  received;  more 
importantly,  it  informs  the  warfighter 
who  to  call  if  the  information  does  not 


Figure  5:  Operationally  Focused  SOA  Diagram 


Figure  6:  Implementation  Oriented  SOA  Diagram 


meet  his  mission  needs. 

With  this  diagram,  the  warfighter  has 
a  definite  knowledge  about  who  will  be 
providing  the  information  required  to 
execute  the  mission  (in  this  case  a  U.S. 
Navy  [USN]  stateside-based  weather 
service  and  a  U.S.  Air  Force  [USAF]  the¬ 
ater-based  service).  There  is  no  need  to 
capture  every  possible  information 
provider,  just  the  most  likely  ones. 
Figure  6  provides  one  possible  technical 
implementation  of  the  same  operational 
need. 

Approaching  the  architectural  dia¬ 
grams  in  this  manner  enables  the 
warfighter  to  be  more  specific  about 
what  information  is  expected  to  be  pro¬ 
vided.  This  specificity  should  also  be 
captured  in  the  information  exchange 
matrix.  The  Department  of  Defense 
(DoD)  Architecture  Framework  vl.5 
provides  a  recommended  information 
exchange  matrix  format.  The  matrix 
emphasizes  the  operational  characteris¬ 
tics  of  the  information  and  is  not 
intended  to  be  an  exhaustive  listing  of 
all  operational  details.  Rather,  this  prod¬ 
uct  is  intended  to  capture  the  most 
important  aspects  of  selected  informa¬ 
tion  exchanges  [2]. 

Starting  with  this  matrix  and  adding 
the  following  data  elements  wiU  help 
capture  the  warfighter’s  expectations  for 
service-provided  information.  These 
elements  address  the  warfighter’s  need 
to  control  how  service-derived  informa¬ 
tion  is  sourced,  stored,  and  acted  upon. 

•  Information  owner.  The  sending 
operational  node  is  not  necessarily 
the  owner  or  producer  of  the  infor¬ 
mation;  sometimes  it  acts  as  a  pass¬ 
through  or  operate  off  of  derived  infor¬ 
mation.  This  is  the  operational  entity 
actually  producing  the  information 
that  the  warfighter  requires  to  exe¬ 
cute  his  mission. 

•  Information  storage.  Does  the 
warfighter  require  his  system  to 
locally  store  the  information? 
Information  such  as  operations 
orders  may  need  to  be  stored,  but 
individual  common  operational  pic¬ 
ture  elements  may  not.  Warfighters 
have  mission  critical  information 
that  must  be  present  regardless  of 
network  or  service  operational  sta¬ 
tus,  and  only  being  able  to  access  this 
information  when  the  network  is  up  is 
not  an  option. 

•  Information  perishability.  How 

long  does  the  information  received 
from  a  service  need  to  stay  opera¬ 
tionally  relevant  to  meet  the 
warfighter’s  mission  requirements?  If 
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the  network  only  allows  a  30  minute 
information  update,  but  the  infor¬ 
mation  is  only  valid  for  15  minutes, 
the  warfighter’s  needs  will  not  be 
met. 

•  Quality.  This  is  a  subjective  or 
objective  measure  that  defines  how 
good  the  information  should  be 
regardless  of  its  source.  Operation¬ 
ally,  the  information  must  meet  this 
threshold;  the  system  must  be  able  to 
cycle  among  available,  trusted  infor¬ 
mation  sources  to  provide  the  best 
information. 

•  Trustworthiness:  This  provides  a 
subjective  or  objective  measure  that 
ranks  the  information  owner, 
enabling  the  warfighter  to  give  prece¬ 
dence  to  one  information  owner 
over  another  based  on  operational 
considerations.  The  warfighter 
should  also  be  able  to  explicitly 
exclude  information  providers  if 
desired. 

•  Information  derivation:  This  in¬ 
cludes  the  business  rules  the  war¬ 
fighter  expects  to  be  implemented  to 
change  raw  data  into  useful  informa¬ 
tion.  There  are  many  possible  and 
correct  ways  to  derive  information. 
As  the  warfighter  will  be  making 
decisions  based  on  the  information, 
not  raw  data,  the  warfighter  needs  to 
be  assured  that  the  way  information 
will  be  generated  meets  its  require¬ 
ments. 

The  following  data  elements  should 
be  added  to  the  matrix  to  capture  how 
the  warfighter’s  expectations  about 
information  produced  by  its  system 
could  be  made  available  through  a  ser¬ 
vice.  Though  similar  to  some  informa¬ 
tion  assurance-related  elements,  they 
serve  a  different  operational  purpose. 

•  Service  discoverability.  Should  the 
information  be  discoverable  by  all 
users  (public),  users  fitting  a  certain 
profile  (restricted),  or  only  upon 
invitation  (private)? 

•  Subscriber  roles.  Should  informa¬ 
tion  exchange  be  restricted  to  other 
users  within  a  defined  chain  of  com¬ 
mand  (role  based)  or  not  (non-role 
based)? 

•  Subscriber  availability.  Will  the 
information  be  available  to  external 
subscribers  continually  (continuous) 
or  in  accordance  with  the  situation 
and  doctrine  (limited)?  This  enables 
other  warfighters  to  determine  how 
much  they  can  depend  on  this  infor¬ 
mation  source. 

•  Subscriber  storage.  Should  the 
information  be  storable  by  the  sub¬ 


scriber?  In  some  instances,  there  is 
an  operational  requirement  to  dis¬ 
able  a  subscriber’s  ability  to  store  ser¬ 
vice-provided  information. 

Current  Implementation 

Weather  information,  a  subset  of  what 
is  known  within  the  DoD  as 
Meteorology  and  Oceanography 
(METOC)  information  was  chosen  to 
showcase  a  net-centric  service  currently 
available  to  warfighters  called  the  Joint 
METOC  Data  Services  Framework 
(JMDSF)  [3]  provided  by  the  Naval 
Oceanographic  Office  or  NAVO- 
CEANO.  The  JMDSF  is  designed  to  be 
a  tool  kit  for  deploying  data-oriented 
services  to  securely  deliver  geospatial 
information  and  is  the  vehicle  used  by 
DoD  to  establish  a  single  access  point 
for  all  METOC  data. 

Using  JMDSF,  NAVOCENO  can 
collate  METOC  data  from  numerous 
government  and  commercial  providers, 
normalize  this  data,  and  publish  it  for  all 
DoD  METOC  information  users. 
JMDSF  is  responsible  to  the  warfighter 
for  recording  where  authoritative  data 
resides,  thereby  easing  the  warfighter’s 
concern  for  authenticating  data  [3].  To 
make  this  service  even  more  useful,  a 
Web-based  front  end  and  file  transfer 
protocol  push  capability  has  been  devel¬ 
oped  to  enable  the  warfighter’s  system 
to  retrieve  METOC  information  in  a 
variety  of  ways  over  networks  of  differ¬ 
ing  capacity. 

No  matter  how  useful,  JMDSF  is  still  a 
technical  implementation  of  a  net-centric 
service,  not  the  operational  activity  pro¬ 
viding  the  information.  That  organization 
will  still  be  NAVOCENO,  the  Air  Force 
Weather  Agency,  or  some  other  opera¬ 
tional  entity.  No  matter  how  good  JMDSF 
is  at  delivering  METOC  data  on  behalf  of 
NAVOCENO,  it  is  still  only  the  current 
technical  solution.  The  operational  need 
to  retrieve  and  act  on  METOC  informa¬ 
tion  does  not  change.  By  describing  this 
need  in  terms  of  the  operational  require¬ 
ment  via  the  technical  service  solution,  the 
warfighter  can  clearly  define  his  require¬ 
ments  and  be  assured  the  technical  solu¬ 
tion  will  implement  it. 

Conclusion 

Net-centric  services  provide  warfighters 
with  improved  access  to  the  information 
they  need  to  make  decisions,  but  only 
when  these  services  are  implemented  in 
a  way  that  reflects  the  warfighter’s 
requirements.  The  services  themselves 
are  invisible  to  the  warfighters,  but  the 
information  the  services  provide  is  not. 


Warfighters  must  be  assured  that 
their  information  needs  will  be  met 
regardless  of  the  technology  that  imple¬ 
ments  their  requirements;  especially 
since  these  services  will  be  eclipsed  by 
newer  technologies  over  time.  So  identi¬ 
fying  netcentric  service  requirements 
should  be  accomplished  early  in  the 
JCIDS  cycle  and  validated  at  each  step. 
Regardless  of  the  technology  that  pro¬ 
vides  information,  the  warfighter’s 
requirement  to  ensure  all  information  is 
timely,  accurate,  relevant,  and  trustwor¬ 
thy  will  not  change. ♦ 
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Applying  a  Service-Oriented  Architecture  to 
Operational  Flight  Program  Development 


Mitch  Chan 

309  Software  Maintenance  Group,  Mill  A.ir  Force  Base 

This  article  describes  how  a  Service-Oriented  Architecture  fSOAJ  was  successfully  applied  to  reuse  data  and  applica¬ 
tions  previously  deployed  in  single-user,  single-computer  configurations.  The  collection  ofi  data  and  applications  was 
transformed  into  a  unified,  multiuser,  client-server plaform  through  the  use  of  open  source  and  standards-based  tech¬ 
nologies  to  minimic^e  development  time,  maximic^e  interoperability,  and  facilitate  collaboration.  The  collaboration  result- 
ingfrom  the  multiuser  network  capability  and  shared  resources  enabled  progress  towards  the  Aerospace  Basic  Quality 
System  Standard  (AS 91 00)  goals  of  lowering  cost,  meeting  schedule,  improving  quality,  and fostering  a  culture  of  con¬ 
tinuous  improvement. 


This  article  describes  the  experiences 
of  the  Hill  Air  Force  Base  software 
engineers  in  the  309  Software 
Maintenance  Group  (SMXG)  who  devel¬ 
op  the  Operational  Flight  Program 
(OFP)  for  the  Fire  Control  Computer 
(FCC)  of  the  Block  30  F-16  aircraft.  This 
article  details  how  the  engineers  incorpo¬ 
rated  an  SOA  to  automate  its  develop¬ 
ment  and  evaluation  process  of  weapon 
coefficients  for  the  delivery  of  air-to- 
ground  munitions. 

The  use  of  open  source  and  stan¬ 
dards-based  technologies  were  key  suc¬ 
cess  factors  for  a  small  team  to  accom¬ 
plish  the  SOA  implementation  in  a  do-it- 
yourself  fashion.  Using  publicly  available 
open  source  software  was  instrumental  in 
minimicfing  the  implementation  time  and 
associated  interruptions  to  the  engineers’ 
normal  OFP  candidate  workflow. 
Choosing  technology  based  on  open 
standards  ensured  that  they  were  maxi- 
mi^ng  the  interoperability  between  sys¬ 
tems. 

The  engineers  were  successful  in  re¬ 
using  data  and  applications  previously 
deployed  in  single-user,  single-computer 
configuration  and  transforming  them 

Figure  1 :  JDAM  Flyouts 


into  a  unified  multiuser  client-server  plat¬ 
form  that  resulted  in  a  building-wide  net¬ 
work  capability.  As  a  result,  non-collocat- 
ed  system  engineers,  developers,  and 
testers  had  access  to  the  design  and  eval¬ 
uation  tools. 

The  improved  collaboration  resulting 
from  the  orchestration  of  network  appli¬ 
cations  and  shared  resources  enabled  the 
engineers  to  achieve  a  return  on  invest¬ 
ment  (ROI)  and  progress  in  meeting  its 
309  Maintenance  Wing’s  AS9100  objec¬ 
tives  of  lowering  cost,  meeting  schedule, 
improving  quality,  and  fostering  a  culture 
of  continuous  improvement. 

This  article  proceeds  by  first  provid¬ 
ing  a  background  section  that  introduces 
the  key  terminology.  Next,  the  article 
describes  the  former  development  and 
evaluation  process.  Then,  the  article  high¬ 
lights  former  inefficiencies  and  provides 
the  solution  which  incorporated  an  SOA 
as  an  integration  tool  to  achieve  better 
results. 

Background 

1.  What  is  a  weapon  coefficient? 

Weapon  coefficients  are  parameters 

used  to  calculate  weapon  trajectories. 


Examples  of  weapon  coefficients 
include  weight,  the  cross-sectional 
area,  and  other  aerodynamic  perfor¬ 
mance  factors. 

2.  What  is  a  footprint? 

For  every  weapon  release  there  is  an 
associated  area  on  the  ground  repre¬ 
senting  the  possible  impact  points. 
This  area  is  referred  to  as  the  foot¬ 
print. 

3.  What  is  a  flyout? 

In  particular,  there  are  four  points  on 
the  boundary  of  the  footprint  that  are 
of  interest:  the  Maximum  Along 
Track  Range,  the  Minimum  Along 
Track  Range,  The  Maximum  Right 
Cross  Track  Range,  and  the 
Maximum  Left  Cross  Track  Range. 
These  points  correspond  to  the 
longest  forward  distance,  the  shortest 
forward  distance,  the  furthest  right- 
forward  distance,  and  the  furthest 
left-forward  distance,  respectively, 
that  the  weapon  can  achieve.  These 
points  are  referred  to  as  flyouts. 

4.  What  is  truth  data? 

Truth  data  is  the  real-world  results 
used  to  compare  calculated  trajecto¬ 
ries  and  impact  points.  Truth  data  is 
typically  provided  by  the  weapon 
manufacturer  in  the  form  of  files  or  a 
computer  application  (weapon 
model)  which  produces  an  output  file. 

Former  Weapon  Coefficient 
Design  Process 

Figure  1  shows  a  top  view  of  a  Joint 
Direct  Attack  Munition  (JDAM)  release. 
In  the  FCC,  the  four  JDAM  flyouts  are  a 
function  of  the  weapon  release  point  and 
the  weapon  coefficients.  The  four  flyouts 
define  a  quad-ellipse  footprint. 

Design  Objective:  Generate  the  opti¬ 
mal  set  of  weapon  coefficients  to  deter¬ 
mine  JDAM  flyouts  for  all  release  points. 

Figure  2  shows  the  former  3- stage 
weapon  coefficient  design  process.  In 
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Figure  2:  Former  Design  Process 
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stage  1,  the  system  designer  ran  the 
weapon  models  to  generate  data  for  the 
purpose  of  comparing  the  results  of  the 
FCC  calculations.  In  stage  2,  the  system 
designer  generated  a  set  of  weapon  coef¬ 
ficients  intended  to  meet  the  design 
objectives  stated  above.  In  order  to  com¬ 
plete  this  task  conveniently,  the  system 
designer  used  a  simulation  of  the  FCC 
OFF.  Finally,  in  stage  3,  the  system 
designer  handed  off  the  weapon  coeffi¬ 
cients  to  the  developer  who  incorporated 
the  weapon  coefficients  into  the  OFF 
code.  Both  the  developer  and  tester  com¬ 
pared  the  test  stand  results  against  the 
simulator  results  used  in  stage  2. 

Inefficiencies  of  the  Former 
Weapon  Coefficient  Design 
Process 

From  a  resource  point- of- view,  the  for¬ 
mer  design  process  relied  predominantly 
on  the  system  designer,  who  performed 
stage  1  and  stage  2.  Because  this  process 
was  serial^  the  developer  and  the  tester 
were  kept  waiting  until  the  end  of  design 
process.  The  system  designer  became  the 
specialist  and  limited  his  bandwidth  (avail¬ 
able  time  and  energy)  to  work  on  other 
projects. 

The  design  process  did  not  scale  well. 
For  practical  purposes,  the  system 
designer  addressed  one  weapon  at  a  time, 
which  caused  a  bottleneck  if  two  or  more 
weapons  were  involved. 

Finally,  and  most  importantly,  the 
design  process  was  not  collaborative.  The 
system  designer  essentially  disappeared 
and  the  design  of  the  weapon  coeffi¬ 
cients  became  a  black  art.  The  single- 
user,  single-computer  deployment  did 
not  encourage  developers  to  invest  time 
in  the  development  tools. 

Enter  SOA 

SO>!\  Purpose 

The  SOA  was  designed,  implemented, 
and  launched  with  the  intent  of  making 
the  design  tools  and  data  accessible  on 
UNIX  desktops  across  the  building  net¬ 
work.  Servers  were  a  mixture  of  personal 
computer  and  UNIX  workstations. 

SOA  Design 

Figures  3  and  4  are  the  UML  diagrams 
that  describe  the  design  of  the  SOA. 
Figure  3  shows  the  five  scenarios  or  use 
cases.  Figure  4  (see  page  22)  describes  the 
orchestration  sequence  of  the  user’s 
client  application.  Note  that  the  fifth  Use 
Case  Store  Results  was  added  with  the 
intent  to  replace  data  that  was  previously 
stored  in  personal  directories  with  a  cen¬ 


tral  storage  repository. 

Figure  4  elaborates  some  details  of 
the  use  cases  discussed  earlier.  Note  that 
results  are  stored  in  a  database  versus 
files. 

SO/l  Implementation 

Remote  access  to  the  database  and  the 
weapon  models  were  provided  using 


open  source  Web  Services.  The  Web  ser¬ 
vices  were  constructed  using  two  Java  2 
Enterprise  Edition  (J2EE)  Web  servers. 
The  weapon  models  were  accessed  using 
a  SUN  Microsystems  Java  Web  Services 
Development  Fack  server.  Data  Access 
Objects  were  exposed  across  the  network 
using  an  Apache  Tomcat  Web  server  with 
Axis  to  provide  the  Web  services  connec- 


Figure  3:  Use  Case 
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Figure  4:  Sequence  Diagram 


tion,  and  Spring/Hibernate  to  provide 
the  data  access  objects,  persistence, 
object-relational  mapping,  and  database 
connection. 


The  choice  to  use  open  source  soft¬ 
ware  greatly  accelerated  the  implementa¬ 
tion  since  a  major  coding  effort  was 
avoided.  The  majority  of  the  effort  was 


tweaking  pre-existing  Java  source  code 
and  editing  of  extensible  Markup 
Language  configuration  files.  The  use  of 
standards-based  technology  on  the  serv¬ 
er-side  such  as  Web  services  ensured 
maximum  interoperability  and  tools  to 
create  client  applicationsf 

The  lab  workstation  running  the  test 
stands  was  accessed  via  UNIX  Remote 
Login  and  Remote  Shell  Programming 
since  the  client  and  server  workstations 
both  ran  UNIX. 

Orchestration  of  the  weapon  models, 
the  database,  and  the  test  stands  was  per¬ 
formed  using  Matrix  Laboratory  (MAT- 
LAB)  in  concert  with  Perl  to  create  a  rich 
client  interface.  MATLAB  and  Perl  were 
chosen  as  client  orchestration  tools  since 
they  were  native  to  the  client  Sun  work¬ 
stations. 

MATLAB  was  chosen  primarily 
because  of  its  visualization  tools,  graphi¬ 
cal  user  interface  interfacing  tools,  math 
library,  and  toolboxes.  Most  of  the  engi¬ 
neers,  especially  the  recent  hires,  had 
plenty  of  hands  on  experience  with 
MATLAB.  Perl  was  used  for  its  regular 
expression  capability  to  handle  text  input 
and  output.  Perl  also  had  the  ability  with 
its  Simple  Object  Access  Protocol- Lite 


Figure  5:  Enterprise  Diagram 
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(SOAP-Lite)  package  to  create  a  Web  ser¬ 
vices  client  simply  by  setting  its  service 
pointer  to  the  URL  of  the  Web  Services 
Definition  Language  file. 

Figure  5  shows  the  final  Enterprise 
Diagram  for  the  SOA.  Note  that  the  sim¬ 
ulator  does  not  appear  since  it  runs  local¬ 
ly  on  the  client  UNIX  workstation. 

S04  Innovations 

20  Minutes  to  20  Seconds 

One  of  the  first  initiatives  was  to  reduce 
the  role  of  the  simulator  and  develop 
directly  on  the  test  stand.  The  major  hur¬ 
dle  was  the  length  of  time  required  to 
check  whether  the  coefficient  changes 
were  right  or  wrong.  Coefficient  changes 
had  to  be  incorporated  in  the  OFP  code. 
Then  the  OFP  code  had  to  be  re-com¬ 
piled  which  took  more  than  20  minutes. 

The  contractor  responsible  for  the 
test  stands  recommended  and  imple¬ 
mented  a  workaround  to  speed  up  the 
process.  The  contractor  added  a  capabili¬ 
ty  to  upload  weapon  coefficient  files 
which  took  only  20  seconds.  The  new 
process  of  incorporating  coefficient 
changes  in  a  file  and  uploading  the  file 
was  simple  and  fast.  With  the  new 
process,  it  became  practical  to  develop 
directly  on  the  test  stand. 

Multiple  Sessions  on  the 
Desktop 

Using  an  older  version  of  MATLAB 
(Vers.  5  versus  Vers.  14)  enabled  multiple 
MATLAB  client  sessions  to  run  on  the 
UNIX  desktops.  This  enabled  multiple 
projects  to  be  open  at  one  time.  Perl,  in 
concert  with  its  SOAP-Lite  package, 
facilitated  the  use  of  an  older  version  of 
MATLAB  (Vers.  5)  which  did  not  have 
the  Web  services  remote  access  capability 
but  was  less  of  a  central  processing  unit 
and  memory  hog. 

ROI  and  Progressing  Towards  the 
AS9I00  Objectives 

The  AS9100  organizational  objectives  are 
the  following: 

1.  Decrease  cost. 

2.  Meet  or  exceed  schedule. 

3.  Improve  quality. 

4.  Develop  a  culture  of  continual 
improvement. 

Decreasing  Cost 

Cost  saving  was  realized  both  short  term 
and  long  term.  In  the  short  term,  the 
SOA  was  applied  to  the  current  release  of 
the  FCC  OFP.  Expensive  end-of-cycle 
rework  costs  were  avoided  by  getting  the 
design  right  the  first  time.  In  the  long 


term,  cost  saving  was  realized  by  reduced 
man-hours  (50  percent  reduction)  result¬ 
ing  from  the  improved  automation  and 
efficiency.  A  fellow  engineer  working  on 
a  follow-on  project  noted  the  following:  I 
love  the  tools.  I  can  run  the  application,  check 
hack  later,  and  find  all  the  graphs  and  results 
that  I  need. 

hAeeting  and  Exceeding  Schedule 
Requirements 

Removing  the  keystrokes  and  mouse 
clicks  reduced  the  probability  of  operator 
error.  Comparison  between  different 
weapon  coefficients  sets  and  improved 
collaboration  lowered  the  variability 
between  developers  in  designing  weapon 
coefficients.  These  factors  helped  to 
achieve  better  predictability  in  the  execu¬ 
tion  of  the  design  process. 

Improving  Quality 

The  quality  of  weapon  coefficients  could 
be  scored  by  coverage  and  false  positives. 
Coverage  is  the  percentage  of  the  area  of 
truth  model  footprint  covered.  Valse  posi¬ 
tives  are  the  number  of  impact  points 
lying  outside  the  truth  model  footprint. 
Also,  the  number  of  release  points  on  the 
test  stand  was  increased  by  more  than 
1,000  percent.  The  previous  method  was 
too  time  consuming  to  allow  scoring  of 
more  than  40  release  points  per  set  of 
weapon  coefficients  (over  400  coeffi¬ 
cients  tested  at  a  time).  The  efficiency  of 
the  new  method  now  allows  us  to  score 
up  to  1,100  release  points  per  set  of  coef¬ 
ficients. 

Developing  a  Culture  of  Continual 
Improvement 

The  SOA  enabled  a  more  data-driven 
design  process.  As  alluded  to  earlier,  the 
scores  coverage  and  false  positives  could  be 
measured  from  the  test  run  data  recorded 
in  the  database.  Adding  more  release 
points  over  a  full  range  of  release  condi¬ 
tions  increased  the  statistical  significance 
of  these  scores.  Using  the  current  scores 
as  a  feedback  mechanism,  the  developer 
could  further  refine  the  weapon  coeffi¬ 
cients  to  produce  better  scores  for  the 
next  design  iteration. 

Lessons  Learned 

The  engineers  considered  a  base-wide 
network  version  of  the  SOA.  However, 
servers  and  applications  on  the  base-wide 
network  were  subject  to  quarterly  time 
compliance  network  orders  and  vulnera¬ 
ble  to  any  collateral  damage  resulting 
from  patch  pushes  to  update  the 
Microsoft  Operating  System  and 


Standard  Desktop  Configuration.  In  the 
end,  the  engineers  decided  to  stay  off  the 
base-wide  network  to  avoid  the  extra 
computer  administration  and  mainte¬ 
nance. 

Conclusion 

This  article  presented  SOA  from  the 
front  line  and  trenches  view  of  software 
OFP  development  at  Hill  Air  Force  Base. 
An  SOA  applied  to  automate  software 
development  process  was  introduced.  An 
overview  of  the  inception,  elaboration, 
construction,  and  transition  was  covered. 
Finally,  no  discussion  of  an  SOA  would 
be  complete  without  evaluating  the  ROI. 
ROI  was  presented  in  the  framework  of 
meeting  the  309  Maintenance  Wing 
AS9100  core  objectives.^ 

Note 

1.  Deliverables  from  the  Basic  Profile 
Working  Group.  2007.  WS-I  Web 
Services  Interoperability  Organi¬ 
zation.  6  June  2007  <www.ws-i.org  / 
deliverables/workinggroup.aspx? 
aspx?wg=basicprofile>. 
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For  Net-Centric  Operations,  the  Future  Is  Federated 

John  Michels en 

iTKO,  Inc. 

SQA  (Service-Oriented  A.rchitecture)  is  an  ideal  strategy  for  enabling  net-centricity  across  shared  application  environ¬ 
ments.  P)Ut  before  materiel  providers  can  realif^e  the  flexibility  and  reuse  advantages  of  migrating  systems  to  a  shared 
SOy4  model,  how  can  they  avoid  the  risk  of  missed  end-customer  requirements?  A^chieving  a  sense  of  trust  in  SO  A 
requires  more  than  the  right  development  and  testing  technologies.  Net-centricity  requires  constant  validation  and  a  shared 
certification  process  to  ensure  that  applications  are  meeting  the  needs  of  the  warfighter  —  even  as  the  shared  technology 
environment  changes  and  evolves. 


Leading  institutions  are  moving  toward 
net-centric  systems:  highly  distrib¬ 
uted  and  flexible  methods  for  delivering 
required  technology  in  a  shared,  reusable 
way  to  support  operations.  Achieving 
net-centricity  in  the  military  and  other 
government  agencies  will  require  both 
organizational  policies  for  sharing  a  com¬ 
mon  set  of  goals  and  technology  strate¬ 
gies  like  SOA. 

However,  there  are  good  reasons  why 
divisions  often  build  and  maintain  their 
own  monolithic  applications:  a  lack  of 
trust.  How  can  you  be  sure  that  a  third 
party  will  deliver  the  required  functionali¬ 
ty  if  they  are  not  on  the  line  to  make  it  work 
for  you?  Realizing  an  effective  federated 
SOA  strategy  in  mission-critical  theatres, 
such  as  warfighter  scenarios  or  air  traffic 
control,  requires  establishing  trust  between 
peer  units  with  services  managed  outside 
of  the  vertical  chain  of  command. 

Technology  innovation  around  SOA 
is  happening  on  a  rapid  scale  within  both 
defense  and  civilian  government  agen¬ 
cies.  This  change  is  being  driven  by  eco¬ 
nomic  and  operational  concerns  that  the 
business  world  at  large  may  not  fully 
comprehend.  Indeed,  a  typical  business 
technologist  may  comment  on  the  opera¬ 
tional  and  budgetary  bloat  of  federal 
organizations,  but  reality  demonstrates 
that  there  is  fierce  competition  for  invest¬ 
ment  dollars  within  the  public  sector. 
Programs  must  reach  milestones  of  suc¬ 
cess,  despite  resource  and  time  con¬ 
straints,  and  within  a  potentially  even 
more  dynamic  environment  than  the  typ¬ 
ical  commercial  enterprise. 

By  pushing  for  long-term  goals,  the 
public  sector  provides  value  to  taxpayers 
by  helping  create  a  purpose-driven  market 
for  technology  investments.  After  all, 
where  did  we  get  the  Internet  itself 
(Defense  Advanced  Research  Projects 
Agency-net  [DARPAnet])?  Or  the  quality 

®  CMMI  is  registered  in  the  U.S.  Patent  and  Trademark 
Office  by  Carnegie  Mellon  University. 


and  implementation  best  practices  of 
Capability  Maturity  Model  Integration 
(CMMI)  or  the  Information  Technology 
Infrastructure  Library  (ITIL)T 

The  common  goals  of  many  govern¬ 
ment  and  defense  agencies  will  create  a 
purpose-driven  market:  a  notional  archi¬ 
tecture  where  services  can  be  published 


pushing  for 
long-term  goals,  the 
public  sector  provides 
value  to  taxpayers  by 
helping  create  a 
purpose-driven  market 
for  technology 
investments  - 
opportunities  for 
innovation  that  the 
stockholder-driven 
company  can 
never  realize.^* 

and  consumed  through  a  central,  shared 
authority  and  knowledge  base  while 
retaining  the  flexibility  to  meet  opera¬ 
tional  and  business  needs. 

Pertaining  to  the  government  as  a 
model  SOA  example,  Dave  Linthicum  of 
the  Linthicum  Group  said  the  following: 

I  think  that  the  government  can 
benefit  most  from  SOA,  consider¬ 
ing  the  nature  of  their  business 
and  the  underlying  need  to  have 
many  systems  interoperate. 


However,  there  needs  to  be  a  real¬ 
istic  understanding  of  the  issues  at 
hand,  and  perhaps  they  need  some 
new  approaches  other  than  build¬ 
ing  architectures  that  look  like 
archeological  layers  of  past  IT 
contracts.  I  do  think  some  of  the 
more  spectacular  SOA  successes 
will  come  from  the  government 
side.  [1] 

We  can  think  of  this  system  just  like 
we  think  of  the  idea  of  multiple  state 
governments  operating  within  a  federal 
government.  Each  state  has  its  own  laws, 
objectives,  and  budgets,  but  all  of  the 
states  in  the  system  are  also  governed 
through  a  federal  authority.  This  model 
can  also  be  applied  to  SOA  application 
architectures,  to  define  a  Federated  SOA. 

The  Federated  SOA  will  provide  a 
leading  indicator  for  where  net-centric 
software  innovation  is  headed  for  the 
business  world.  The  innovations  that  led 
up  to  DARPA  or  CMMI  were  not 
designed  simply  to  make  money  or  opti¬ 
mize  cost.  They  were  born  from  the  idea 
that  we  have  a  specific,  targeted  outcome 
to  reach.  Let  us  take  a  step  forward  to 
prove  why  governmental  approaches  are 
going  to  produce  leading-edge  techniques 
for  SOA  governance. 

Challenges 

Federal  agencies,  just  like  any  other  glob¬ 
al  enterprise,  are  now  at  a  crossroads  for 
establishing  an  SOA  strategy  in  a  world 
where  no  single  strategy  can  possibly 
cover  every  need.  Countless  siloed  tech¬ 
nologies  currently  exist  as  acronyms 
within  each  operational  unit.  Supporting 
and  maintaining  so  many  separate  plat¬ 
forms  becomes  untenable  over  time,  as 
any  additional  functionality  or  code  adds 
to  the  existing  technologies  in  a  stovepipe 
fashion.  Each  new  customization  and 
every  line  of  code  written  for  one  of 
these  stovepipe  technologies  results  in  a 
long-term  annuity  that  will  have  to  be 
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paid  back  and  supported  over  time. 

Organizational:  Vertical  Trust  vs. 
Horizontal  Competition 

For  net-centric  computing  environ¬ 
ments,  vertical  trust  (i.e.  trust  up  and 
down  a  common  chain  of  command)  is 
far  easier  to  achieve  than  hori^^ontal  trust 
(i.e.  across  authority  domains  or  organi¬ 
zational  units). 

Vertical  Trust 

In  most  organizations,  vertical  trust  is 
relatively  easy  to  come  by  and  already 
exists.  The  line  of  reporting  structure 
typically  creates  the  sense  of  reuse  stan¬ 
dardization  and  the  ability  to  leverage 
vertically  within  an  organization. 

As  shown  in  Figure  1,  in  vertical 
hierarchies  within  organizations,  there  is 
an  expected  level  of  shared  trust. 

•  The  higher  levels  within  can  expect 
the  underlying  teams  to  build  to  order 
technology  assets  and  maintain  them 
according  to  defined  policies. 

•  Supporting  providers  can  expect  the 
requestor  to  leverage  the  developed 
materiel  capability  services  according 
to  well-understood  and  defined 
requirements. 

Horizontal  Trust 

At  the  highest  levels,  horizontally  across 
peer  groups,  a  lack  of  trust  is  usually  not 
the  case  (see  Figure  2).  Ironically,  a  lot 
of  organizations  that  share  common 
goals  tend  to  foster  a  not  invented  here 
mentality  that  inhibits  collaboration 
between  horizontal  peer  groups.  That  is 
the  source  of  why  horizontal  gover¬ 
nance  is  such  a  critical  aspect  to  SOA 
adoption. 

Across  different  operational  or  busi¬ 
ness  units,  coordinating  the  proper  use 
of  a  service  can  be  difficult. 

•  Materiel  or  service  providers  want  to 
establish  reuse  of  their  services,  but 
they  are  answerable  to  different 
stakeholders. 

•  Upstream  consumers  of  services 
may  not  provide  clear  enough  use 
cases  or  policies  of  how  they  will 
leverage  the  services. 

•  Therefore,  teams  often  build  and 
maintain  redundant  functionality  in 
vertical  silos. 

Redundant  efforts  create  inefficien¬ 
cies  when  software  functionality  gets 
duplicated.  Therefore,  before  we  can 
realize  the  value  of  reusable  services 
offered  within  a  federated  software 
strategy,  agencies  must  learn  to  establish 
trust  horizontally,  across  organizational 
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Figure  1 :  Vertical  Governance  Along  a  Chain  of  Command 


and  chain-of-command  boundaries. 

Federated  Technologies  Are 
Heterogeneous 

The  operational  rules  and  behaviors  of 
an  SOA  live  in  the  middle  tier  (between 
the  interface  and  the  database  layers), 
iterating  within  an  alphabet  soup  of  tech¬ 
nology  acronyms  (for  example,  XML, 
SOAP,  WSDL,  ESBs,  etc.),  which  are 
exposed  as  services.  These  services  are 
technology  assets  that  can  be  managed  or 
published  within  your  own  authority 
domain  or  reside  outside  the  department 
or  even  outside  the  organization. 

Services  Need  Not  Be  Web  Services 

Many  technology  vendors  simply  equate 
Web  services  (WSDL/SOAP^)  with  SOA; 
from  a  testing  point  of  view,  they  equate 
the  testing  of  Web  services  with  the  test¬ 
ing  of  SOA. 

While  it  is  true  that  a  number  of  ini¬ 
tiatives  for  doing  SOA  are  very  Web  ser¬ 
vices- centric,  the  Aberdeen  Group’s  last 
research  on  this  points  out  that  only 
about  50  percent  of  the  SOA  initiatives  at 
best-in-class  companies  are  Web  services- 
based  [2].  There  are  a  variety  of  tech¬ 
nologies  being  used  to  create  that  com¬ 
moditized  middleware  for  SOA.  While 
Web  services  can  be  a  good  integration 


strategy,  other  technologies  are  valid  and 
possibly  better  for  a  given  organization 
than  a  Web  services  stack,  for  instance, 
using  an  Enterprise  Service  Bus  with  lit¬ 
tle  reliance  on  Web  services. 

The  distinction  between  Web  services 
and  SOA  testing  in  general  is  important. 
There  is  more  than  one  way  to  build  an 
SOA.  Teams  need  to  test  the  implemen¬ 
tation  and  side-effects  that  occur  across 
heterogeneous  technologies,  as  opposed 
to  just  a  selected  middleware  layer  like 
SOAP. 

As  illustrated  in  Figure  3  (see  page 
26),  there  is  inevitable  complexity  under 
the  surface  of  any  large-scale  implemen¬ 
tation.  In  an  SOA,  more  unique  technology 
types,  multiplied  by  more  points  of  connection, 
equals  an  exponential  increase  in  possible  fail¬ 
ure  points. 

Heterogeneous  technologies  will 
never  go  away  and  leave  behind  a  totally 
homogenous  platform.  There  are  several 
reasons  for  this. 

1.  Legacy  systems  cannot  just  be 
turned  off.  Technologists  are  always 
attempting  to  provide  more  flexible 
application  architecture  at  a  lower 
cost  to  their  constituents.  As  tech¬ 
nologies  evolve,  we  almost  never  have 
a  cost  justification  to  retire  existing 
systems  and  replace  them  with  the 
new  technology.  The  Web  services 


Figure  2:  Horizontal  Trust  Across  Organizational  Boundaries  Bears  More  Risk  of 
Misunderstandings  or  Missed  Requirements 
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Figure  3:  Underneath  the  Expected  Simplicity  of  a  Created  Net-centric  Service-Based  Workflow,  a 
Myriad  of  Distributed  Existing  and  Disparate  Technologies  Must  Be  Managed  and  Tested 


stack  now  considered  modern  tech¬ 
nology  will  soon  be  outdated,  and  an 
integration  strategy  to  leverage  these 
soon-outdated  applications  with 
tomorrow’s  better  thinking  will  be 
needed. 

2.  Resistance  to  vendor  monopoliza¬ 
tion.  A  we  do  it  all  vendor  can  promise 
uniform  specifications  and  the  bene¬ 
fits  of  increased  scale,  but  for  larger 
clients,  tying  the  entire  technology  to 
the  platform  of  a  single  vendor  may 
inhibit  specialization  and  become  per¬ 
ceived  as  a  long-term  risk  if  develop¬ 
ment  priorities  (or  pricing  structures) 
change.  Thus,  even  new  applications 
are  built  on  a  variety  of  technology 
platforms. 

3.  Distributed  authority  domains. 

Federated  organizations  have  multiple 
chains  of  command.  Operational 
units  have  unique  functional  needs 
from  technology  assets,  therefore, 
they  naturally  desire  to  keep  some 
teams  and  service  assets  under  direct 
control. 

To  trust  SOA,  a  much  deeper  level  of 
collaboration  testing  must  occur  as  a  con¬ 
tinuous  process,  not  an  event.  The  ser¬ 
vices,  and  the  expected  uses  of  them, 
must  be  submitted  and  certifiable  (func¬ 
tionally  and  at  load)  to  the  community 
relying  on  the  SOA. 

Policies  Are  Hard  to  Follow 

A  policy  basically  defines  an  expected 
behavior.  Governance  of  SOA  applica¬ 
tions  goes  hand-in-hand  with  defining  and 
enforcing  policies  in  order  to  achieve  con¬ 
trol  of,  and  trust  in,  the  SOA  application. 
But  what  is  policy?  Often  technolo¬ 


gists  mistakenly  approach  policy  as  a 
solely  structural  concern.  For  instance,  is 
the  syntax  of  the  XME  message  formed  correct¬ 
ly?  Do  the  components  connect  according  to  our 
selected  standards?  Structural  concerns  are 
just  one  aspect  of  policy  that  needs  to  be 
addressed. 

Once  structural  standards  are  in 
place,  a  behavioral  definition  of  policy 
wiU  become  a  determining  factor  in  the 
success  of  any  SOA  endeavor.  A  behav¬ 
ioral  policy  basically  defines  what  the  sys¬ 
tem  should  operationally  do  to  support 
its  intended  use. 

We  need  to  realize  that  the  organiza¬ 
tion  will  not  want  to  write  policy  con¬ 
cerned  about  technical  standards.  Rather, 
the  organization’s  version  of  policy  wiU 
be  the  following: 

•  I  really  need  functional  integrity  on 
this  particular  transaction  activity  of 
the  system. 

•  I  reaUy  need  the  response  on  resource 
availability  to  be  accurate  within  30 
minutes  of  my  request. 

•  I  cannot  allow  stale  data  to  be  report¬ 
ed  as  current  activity  in  the  field. 
Net-cen tricity  is  about  sharing  opera¬ 
tional  functions  and  placing  expectations 
upon  the  systems  that  are  implementing 
those  policies.  That  is  meaningful  policy. 
SOA  policy  must  focus  on  the  functional 
integrity  of  the  application  —  the  quality 
and  reliability  of  the  end  customer  expe¬ 
rience,  accuracy  of  data,  and  runtime  per¬ 
formance  of  the  application. 

Service  Consumption  Is  Not  Free 

There  is  a  commonly  held  (and  some¬ 
what  sentimental)  notion  that  once  the 
SOA  architecture  is  in  place,  it  will  pro¬ 


vide  an  environment  of  published  ser¬ 
vices  that  multiple  consumers  can  basi¬ 
cally  leverage  within  their  own  workflows 
at  little  or  no  cost.  This  model  is  valid  for 
very  non-differentiated  or  commoditized 
services  such  as  news  feeds,  simple  calcu¬ 
lators  for  unit  conversions,  and  the  like. 

Take  for  instance  a  small  application, 
developed  specifically  for  a  military  unit’s 
internal  use.  The  certification  level,  and 
the  level  of  structural,  behavioral,  and 
performance  policy  wiU  not  be  nearly  as 
high.  The  maintenance  cost  for  that  ser¬ 
vice  will  be  much  lower  and  there  wiU  be 
much  less  risk  and  testing  rigor  in  chang¬ 
ing  that  service  when  a  finite  set  of  con¬ 
sumers  are  impacted  by  that  change. 

Now  consider  a  mission-critical, 
broadly  reused  service  that  will  have  a 
widely  distributed  use  among  all  military 
divisions,  including  some  that  the  devel¬ 
opment  team  may  not  even  yet  be  aware 
of.  That  creates  an  increased  cost  of  pro¬ 
ducing  a  service  that  is  robust  over  time 
and  reusable.  If  consumption  creates 
cost  and  effort  for  the  producer,  then  the 
consumption  itself  should  not  be  free. 

A  reckoning  must  occur  when  a  con¬ 
suming  project  team  gets  benefit  from  an 
existing  reusable  service  that  is  properly 
maintained.  Otherwise,  the  production  of 
robust,  quality  services  is  penalized.  An 
increased  cost  burden,  without  an  associ¬ 
ated  increase  in  the  budget  for  that  service 
to  be  reused,  will  actually  threaten  that  ser¬ 
vice’s  long-term  quality  and  adherence  to 
the  policy  the  consumer  expected. 

Consumption  of  existing  services  can 
reduce  the  cost  and  effort  of  producing  a 
solution.  Over  time,  the  service  con¬ 
sumer  must  bear  some  accountability  to 
the  publisher  of  those  services.  If  aU  par¬ 
ties  involved  in  SOA  realize  that  there  is 
no  free  beer,  the  end  result  will  be  a  more 
sustainable  marketplace  of  services. 

Solutions 

Establishing  SOA  Governance 
Enhances  Capabilities 

The  primary  goal  of  net-centric  comput¬ 
ing  is  to  enhance  the  ability  of  each  orga¬ 
nization  to  efficiently  meet  the  needs  of 
the  warfighter.  If  the  level  of  trust  is 
high,  the  organization  can  rely  on  both 
the  historical  and  runtime  validation  of 
every  service  it  depends  on.  Without 
SOA  governance,  SOA  remains  a  chaotic, 
free-form  exercise. 

If  the  extended  organization  plans  to 
overcome  the  vertical  silos  and  rely  on  an 
application  made  from  separately  man¬ 
aged  services,  each  being  developed  and 
maintained  on  their  own  life  cycle,  what 
are  the  rules  of  the  road? 
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According  to  Gartner  analyst  Frank 
Kenney  [3],  SOA  governance  is  made  up 
of  three  components:  the  Registry  (or 
Repository)  where  the  assets  of  SOA  are 
stored  and  catalogued,  Volicy  which  is 
meant  to  keep  track  of  the  rules  of  engage¬ 
ment  and  service  levels  expected  in  SOA, 
and  SOA  Testing  that  is  needed  to  ensure 
SOA  life-cycle  quality 

What  good  is  a  registry  if  it  contains 
assets  that  are  not  sufficiently  tested  at 
both  the  service  and  the  implementation 
layer?  Strong  testing  is  required  to  ensure 
that  the  SOA  application  continually 
meets  the  business  needs  —  in  develop¬ 
ment,  integration,  and  deployment.  The 
longer  testing  is  delayed  as  an  aspect  of 
SOA  governance,  the  wider  the  deviation 
becomes  between  expected  and  delivered 
results. 

Defining  a  Big  Policy 

As  we  continue  to  mature  the  SOA  gover¬ 
nance  space,  the  policy  area  appears  to  be 
the  one  that  is  the  most  immature.  In  the 
near  future,  governance  will  become  syn¬ 
onymous  with  policy.  Each  type  of  SOA 
policy  is  vitally  important  to  achieving  reli¬ 
ability  and  trust,  as  shown  in  Table  1 . 

Currently,  most  technologists  focus 
on  testing  the  structural  policy  type  men¬ 
tioned  in  Table  1 .  True,  integration  stan¬ 
dards  are  important,  but  once  those  types 
of  problems  are  solved,  behavioral  and 
performance  level  validation  will  gain 
prominence.  After  all,  what  good  is  certi¬ 
fying  structural  policy  if  the  SOA  appli¬ 
cation  does  not  perform  its  function  cor¬ 
rectly  and  at  the  expected  scale,  design 
time,  run  time,  and  change  time? 

The  Certification  Environment:  Two 
Sides  of  the  Coin 

There  are  two  critical  certification  flows 
to  a  robust,  federated  test  and  policy  val¬ 
idation  strategy:  a  publish  cycle  and  a 
consume  cycle.  These  can  be  considered 
federal-level  processes  that  form  a  certifi¬ 
cation  environment,  a  central  authority 
offering  the  rules  of  the  road  for  creating 
and  offering  services,  then  leveraging 
these  created  services  in  an  expected 
fashion.  The  need  for  a  publish  cycle  is 
evident:  A  standards  body  must  establish 
and  enforce  criteria  that  provide  for  an 
environment  of  trust  to  encourage  and 
enable  reuse.  The  consume  cycle  is  equal¬ 
ly  as  important,  as  it  must  properly  lay 
out  the  expected  use  cases  for  published 
services  in  a  realistic  and  enforceable  way. 

The  Publish  Cycle 

A  development  team  that  wants  to  offer 
up  a  service  to  the  community  submits 


Policy  Type 

Definition 

Examples  of  Use 

Structural 

The  services  components  are 
compliant  with  chosen 
integration  standards  and 
reusable  with  the  current 
development,  deployment  and 
governance  platforms. 

-  Do  the  pin  outs  line  up  so  that 
the  components  can  technically 
communicate  with  each  other? 

-  Are  the  services  following 
correct  authentication  protocols? 

-  Is  the  XML  syntax  compliant? 

Behavioral 

The  service  interacts  and 
provides  correct  results  within 
the  context  of  the  workflow  or 
task  that  needs  to  be 
accomplished. 

-  Are  the  results  1  expected 
actually  being  produced? 

-  Does  the  operational  logic  of 
this  service  properly  support  the 
process  it  is  being  used  for? 

Performance 

The  service  can  sustain  the 
performance,  scalability,  and 
reliability  levels  required  overtime. 

-  Can  this  component  produce 
the  results  1  need  with  the 
number  of  users  1  need,  within 
the  time  constraints,  and 
infrastructure  that  1  need  it? 

Runtime 

Expectations  around  the  service 
level  of  the  component  in  the  live 
production  environment. 

-  Expected  response  time  for  this 
service  is  one  second  for  our  top 

20  constituents  and  three 
seconds  for  all  others. 

-  Uptime  must  be  >  99.999 
percent. 

Table  1 :  Defining  Volicy  Types 


their  asset  as  a  proposed  service  for  reuse 
(see  Figure  4).  This  service  is  reviewed  by 
a  cross-domain  group  called  a  certifica¬ 
tion  group  that  must  verify  that  the 
offered  service  conforms  to  expected 
policies  before  making  it  available  to  the 
community.  Next,  the  group  needs  to 
continuously  monitor  and  test  those  ser¬ 
vices,  as  they  may  change  or  fall  out  of 
expected  policy  guidelines. 

How  the  Publish  Cycle  Works 

1.  Offer.  A  developer  or  development 
team  creates  a  new,  uncertified  ver¬ 
sion  of  a  Service  Component  (SC). 


They  can  offer  the  working  SC  along 
with  documentation  to  a  certification 
group  for  testing  and  approval. 
Optionally,  they  can  include  working 
test  cases  as  part  of  the  documenta¬ 
tion  process  to  aid  certification  and 
store  those  in  the  registry. 

a.  Developers  self-assess  quality  by 
creating  tests  against  their  own 
SCs  (whether  it  is  a  technology 
component  or  Web  service) 
before  submitting  them. 

b.  Developer  offers  the  proposed  SC 

to  a  centralized  registry  for  certifi¬ 
cation.  The  development  team  can 


Figure  4:  Publish  Cycle  for  Service  Providers  to  Submit  and  Certify  That  Their  Service  Assets  Will 
Meet  the  Needs  of  the  Net-Centric  Community 
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Figure  5:  Consume  Cycle  for  Sharing  Testing  and  Certification  Processes  in  a  Net-Centric 
Environment 


accelerate  the  process  by  submit¬ 
ting  functional,  performance,  and 
other  tests  to  validate  the  policy 
out  of  the  box. 

2.  Certify.  Certifiers  use  existing  tests 
and  iterate  on  those  tests  to  validate 
that  the  SC  meets  all  required  policies 
at  every  stage  of  the  service’s  life 
cycle.  Tests  are  checked  into  the  test 
registry/repository  alongside  the  ser¬ 
vices,  which  are  rated  according  to 
their  level  of  certification  (each  orga¬ 
nization  defines  its  own  certification 
levels,  for  example,  from  trial  level  of 
certification  to  partially  certified  to  fully 
certified). 

3.  Verify.  Initial  certifications  are  not 
much  good  if  they  are  not  enforced 
later  in  production.  Certifiers  register 
the  test  cases,  and  they  are  run  con¬ 
tinuously  to  validate  that  expectations 
are  met  as  the  application  environ¬ 
ment  evolves.  Continuous  verification 
happens  on  a  regular  time  interval  or 
based  on  any  system  level  event. 

4.  Review.  All  metrics  and  test  informa¬ 
tion  is  published  to  both  certification 
and  publishing  teams  for  reporting 
and  alerting  on  SC  issues.  Alerting 
mechanisms  can  inform  any  develop¬ 
ment  or  deployment  team  of  excep¬ 
tions  or  errors  within  the  certification 
environment. 

The  Consume  Cycle 

The  Consume  cycle  is  equally  important; 
those  who  plan  to  leverage  published  ser¬ 
vices  must  establish  a  model  workflow 
outlining  their  expected  behavior  so  that 
ongoing  change  does  not  cause  the  sys¬ 
tem  to  fail  in  unexpected  ways  (Figure  5). 


How  the  Consume  Cycle  Works 

Consumers  browse  the  registry  of  avail¬ 
able  services  and  use  them  to  define 
workflows  that  consume  one  or  more 
SCs  as  steps  needed  to  complete  an 
objective. 

1.  Discovery.  Development  consumers 
browse  available  SCs  and  their  associ¬ 
ated  published  policies  and  test  cases 
in  order  to  determine  applicability  to 
their  proposed  workflows.  Develop¬ 
ment  teams  can  test  them  using  exist¬ 
ing  tests  or  combined  with  a  target 
workflow  test  (i.e.,  testing  the  validity 
of  the  workflow  in  absence  of  the 
underlying  services). 

2.  Confirm  workflow  and  set  policy. 

Certifiers  verify  that  the  intended  uses 
defined  within  the  consumer’s  work- 
flow  are  achievable,  and  once  the 
workflow  is  certified,  it  is  published 
to  the  registry  as  a  set  of  expected 
behaviors  —  a  policy  —  that  can  be  cer¬ 
tified  via  suites  of  test  cases  that 
accompany  the  workflow. 

3.  Workflow  validation.  Test  suites  for 
workflows  are  checked  into  a  contin¬ 
uous  testing  process  as  policies  for 
continuous  monitoring  of  required 
quality  of  service  —  performance, 
scalability,  and  reliability.  These  tests 
set  the  bar  for  candidate  and  certified 
services  that  are  accountable  to  sup¬ 
port  the  workflow. 

4.  Alerts  and  exceptions.  A  test  dash¬ 
board  provides  key  metrics  to  devel¬ 
opment,  certification,  and  administra¬ 
tion  teams.  Workflows  are  monitored 
for  issues  as  SC  development  life 
cycles  and  demands  on  deployment 


evolve.  If  an  exception,  error,  or 
boundary  condition  event  occurs  that 
violates  one  or  more  workflows, 
stakeholders  can  be  alerted  with  root 
cause  test  cases  provided. 

Most  organizations  have  not  even 
considered  managing  policies  or  tests  for 
how  they  consume  services.  There  is  no 
free  beer  in  SOA.  If  there  are  no  expecta¬ 
tions  placed  upon  the  consumer  of  ser¬ 
vices,  total  chaos  ensues,  and  there  is  no 
governance.  By  defining  the  expected 
behaviors  of  the  consumer,  service 
providers  in  the  network  can  supply  pro¬ 
visions  for  this,  and  validate  that  all  the 
critical  workflows  are  supported  both 
now  and  in  the  future  when  each  new 
release  of  the  service  component  is  pro¬ 
posed. 

A  Center  of  Excellence  for  SOA 
Life-Cycle  Quality 
Go  Horizontal  for  SOA  Excellence 

One  way  to  instill  a  sense  of  horizontal 
trust  across  the  organization  is  through 
an  SOA  Center  of  Excellence  (COE). 
For  example,  consider  an  analogy  of 
states’  rights  vs.  federal  rights.  The  indi¬ 
vidual  divisions  (or  states)  need  to  con¬ 
sider  themselves  autonomous  on  certain 
levels  and  to  owe  certain  rights  at  the  fed¬ 
eral  level;  but  they  also  have  the  opportu¬ 
nity  to  participate  in  how  policies  are  set 
at  that  federal  level,  so  that  it  is  not  just  a 
doirn  from  above  edict  that  immediately  cre¬ 
ates  a  defensive  reaction  instead  of  a  uni¬ 
fied  purpose. 

Booz  Allen  Hamilton  Vice  President 
Art  Fritz  son  noted  the  following: 

I  tend  to  reduce  net- cen tricity  to 
two  questions  that  are  both 
addressed  by  community.  Nave  you 
asked  your  community  for  help?  and 
Nre  you  helping  your  community?  If 
you  get  positive  answers  to  both 
those  questions,  you’ve  got  80-90 
percent  of  what  net-centricity 
promises  just  through  behavioral 
changes.  [4] 

Which  policies  need  to  be  tested  as 
so-called  federal  policies  and  which  can 
safely  be  handled  at  the  state  level?  Policy 
testing  can  be  automated  along  four 
domains:  structural^  behavioral^  peformance, 
and  runtime.  At  the  federal  level,  structur¬ 
al  policy  (or  compliance)  might  be  the 
most  important  aspect,  while  from  a 
state-to- state,  horizontal  kind  of  policy, 
behavioral  and  performance  aspects  will 
perhaps  be  most  important  to  define  and 
test  at  those  levels. 
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Publication  and  consumption  of 
shared  services  will  only  happen  in  an 
environment  where  trust  is  fostered. 
Trust  can  never  exist  unless  empirical 
data  (test  data)  that  supports  assertions 
against  expected  policies  about  a  compo¬ 
nent  (service,  component  module,  etc.) 
can  be  quantifiably  and  continuously 
obtained.  The  levels  of  certification,  and 
what  is  defined  as  important  to  test,  will 
differ  for  different  communities  of  inter¬ 
est  (COIs).  Each  federated  consumer 
may  reuse,  or  not  reuse,  those  assets  that 
will  deliver  efficiently  for  them. 

Life-Cycle  Quality  and  Testing 

Software  testing  in  the  standard  waterfall 
development  cycle  has  long  been  relegat¬ 
ed  to  a  project  milestone  somewhere 
after  development  and  integration  hap¬ 
pens.  But  in  SOA,  life-cycle  quality  is  a 
continuous  part  of  SOA  governance  and 
not  an  event  that  unit  tests  a  specific 
technology  as  a  pre-release  feel  good. 

ZapThink’s  Ron  SchmeEer  said  the 
following  on  SOA  quality: 

Exposing  a  service  is  one  step  in 
the  life  cycle  of  SOA  develop¬ 
ment,  but  it  is  not  even  the  first 
step.  Indeed,  the  step  companies 
take  to  expose  and  execute 
Services  should  be  one  of  the  last 
they  take  as  part  of  a  mature 
architectural  process.  Quality,  in 
particular,  should  be  considered 
before  any  services  are  created.  If 
a  company  has  not  considered 
how  services  will  be  tested,  how 
consumers  will  reliably  succeed  or 
fail  in  their  service  consumption, 
and  how  they  will  iterate  through 
service  versions,  then  any  con¬ 
sumers  that  bind  to  those  initial 
services  will  be  doing  so  at  their 
own  peril.  [5] 

The  organization  needs  complete  testing 
from  the  Web  layer  through  Web  ser¬ 
vices,  databases,  and  all  middle  tiers  of 
the  application.  Merely  testing  at  a  single 
layer  will  not  uncover  missed  require¬ 
ments. 

Also,  testing  should  support  the  entire 
extended  set  of  players  collaborating  on 
SOA,  from  the  process  owners  writing 
the  requirements,  to  the  developers 
implementing  them  in  SOA,  to  the 
Quality  Assurance  teams  verifying  func¬ 
tionality  and  performance. 

SOA  testing  should  be  continuous, 
not  just  in  development  and  integration 
but  in  deployment  because  an  SOA  by 
nature  is  never  a  static  application.  Each 


element  of  the  SOA  is  on  its  own  devel¬ 
opment  and  release  life  cycle. 

The  humble  test  is  just  like  a  bill  sit¬ 
ting  in  Congress  waiting  to  become  a  law 
(or  an  SOA  policy).  In  order  to  get  there, 
it  is  going  to  need  the  support  and  nur¬ 
turing  of  the  SOA  community  at  a  team 
level  and  across  organizations. 

In  other  words,  we  promote  a  test  as 
an  actionable  aspect  of  SOA  governance. 
To  do  this,  the  SOA  test  must  contribute 
more  than  a  specific  technology  check¬ 
point  at  a  specific  point  in  time.  A  test 
must  span  the  SOA  application  continu¬ 
ously,  and  in  so  doing  it  becomes  a  verifi¬ 
able  SOA  policy. 

Conclusion 

This  article  has  outlined  several  key 
strategies  for  leading  the  way  to  a  true 
net-centric  approach  to  SOA  life-cycle 
quality  and  testing,  which  is  one  of  the 
three  primary  components  of  SOA  gov¬ 
ernance. 

Success  in  SOA  is  not  something  you 
can  buy  as  a  software  package;  it  is  some¬ 
thing  you  must  do.  In  fact,  the  quality  of 
your  policy  and  the  relevance  of  your  cer¬ 
tification  efforts  depends  entirely  upon 
the  skill  and  discipline  level  of  all  partici¬ 
pants  in  the  SOA  strategy.  The  architect, 
the  developer,  the  tester,  and  the  require¬ 
ments  owner  must  work  to  establish 
trust,  whether  from  a  development  per¬ 
spective  or  a  quality  perspective. 

The  entire  extended  organization 
needs  to  adopt  an  SOA  COE  —  the  fed¬ 
eral  authority  that  helps  the  underlying 
states  align  around  common  goals.  If  we 
think  about  what  the  SOA  COE  must 
look  like,  then  certainly  there  needs  to  be 
a  set  of  participants  that  are  not  behold¬ 
en  to  any  particular  one  of  the  divisions 
involved,  but  there  also  needs  to  be  sig¬ 
nificant  membership  from  all  of  those 
who  will  be  involved  so  that  we  get  the 
participation.  After  all,  this  is  not  us  vs. 
them  —  net- cen tricity  is  all  of  us  in  the 
same  boat  together. ♦ 
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Notes 

1.  ITIL  stands  for  Information 
Technology  Infrastructure  Library,  a 
set  of  best  practices  for  delivering 
technology,  used  globally  but  largely 
originated  in  the  United  Kingdom. 
For  more  information  see  <www.itil. 
co.uk/>. 

2.  WSDL  stands  for  Web  Services 
Description  Language,  which  is  a  pro¬ 
tocol  for  identifying  the  properties  of 
a  directory  or  library  of  Web  Services. 
SOAP  stands  for  Simple  Object 
Access  Protocol,  which  is  the  com¬ 
mon  method  (a  form  of  XML)  for 
transmitting  data  objects  among  Web 
Services  and  other  technologies.  For 
more,  see  <www.w3.org/TR/wsdl>. 
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Web  Sites 


Service-Oriented  Architectures  (SOAs) 

www.service-architecture.com 

This  site  will  help  you  get  started  with  Web  Services  and  SOAs. 
It  features  free  articles,  services,  and  product  listings  that  can  be 
used  to  develop  an  SOA  using  Web  Services.  There  are  nearly 
400  pages  of  online  articles  covering  many  types  of  SOAs  that 
provide  an  extensive  overview  of  Web  Services,  related  stan¬ 
dards,  and  technologies  that  can  be  used  in  SOAs.  Web  Services 
make  up  a  connection  technology  and  is  a  way  to  connect  ser¬ 
vices  together. 

Information  Technology  Library  (ITL) 

www.itl.nist.gov 

ITL  has  been  charged  to  lead  the  nation  in  utilizing  existing  and 
emerging  IT  to  meet  national  priorities  that  reflect  the  country’s 
broad-based  social,  economic,  and  political  values  and  goals.  Its 
extended  charge  continues  under  the  Federal  Information 
Security  Management  Act  to  develop  cybersecurity  standards, 
guidelines,  and  associated  methods  and  techniques.  Charged 
under  other  legislation,  such  as  the  U.S.  Patriot  Act  and  the 
Help  America  Vote  Act,  ITL  is  addressing  the  major  challenges 
faced  by  the  nation  in  the  areas  of  homeland  security  and  elec¬ 
tronic  voting. 

Service  Oriented  Enterprise  (SOE) 

www.serviceoriented.org 

ServiceOriented.org  was  developed  to  educate  readers  about  the 
benefits  and  attributes  of  an  SOE.  ServiceOriented.org  is  part 
glossary,  part  educational  story.  The  site  does  not  have  a  rigid 
navigational  structure,  but  instead  invites  readers  to  wander,  fol¬ 
lowing  links  to  related  topics  as  desired. 

U.S.Army  Enterprise  Resource  Planning 
Service-Oriented  Architecture  Resource 
Center 

www.army.mil/ escc/ erp/ soa.htm 

As  the  Army  embarks  on  transforming  its  warfighting  capabili¬ 
ties,  it  is  imperative  that  the  business  capabilities/enablers/ 
processes  transform  to  support  the  warfighter.  Enterprise 
Resource  Planning  (ERP)  systems  provide  an  integrated  suite  of 
Information  Technology  applications  that  support  the  end-to- 


end  business  operations  of  an  entire  organization.  The  ERP 
Resource  Center  is  designed  to  provide  enterprise  process  own¬ 
ers,  program  executive  officers,  program  managers,  and  others 
involved  in  the  business  transformation  of  the  Army  with 
detailed  information,  supporting  documents,  and  tools  and 
techniques  regarding  the  use  of  ERP  systems. 

The  World  Wide  Web  Consortium  (W3C) 

www.w3.org 

The  W3C  develops  interoperable  technologies  (specifications, 
guidelines,  software,  and  tools)  to  lead  the  Web  to  its  full  poten¬ 
tial.  It  is  a  forum  for  information,  commerce,  communication, 
and  collective  understanding.  On  this  site,  you  will  find  W3C 
news,  links  to  W3C  technologies,  and  ways  to  get  involved. 
New  visitors  can  find  help  under  the  Finding  Your  Way  heading. 

SOA  Magazine 

www.soamag.com 

The  SOA  Magazine  is  a  monthly  online  publication  dedicated 
to  publishing  specialized  SOA  articles,  case  studies,  and  papers 
by  industry  experts  and  professionals.  Amidst  all  the  SOA-relat- 
ed  activity  that  is  currently  under  way,  there  still  remains  a  sig¬ 
nificant  amount  of  confusion  as  to  what  exactly  constitutes  a 
SOA.  Some  qualify  an  SOA  project  by  the  fact  that  Web 
Services  technologies  are  being  used,  while  others  classify  SOA 
as  a  Web-centric  variation  of  object-oriented  design.  The  com¬ 
mon  criteria  for  contributions  is  that  each  explores  a  distinct 
aspect  of  service-oriented  computing. 

Wikipedia 

http://en.wikipedia.org/wiki/service-oriented-architecture 
This  Wikipedia  Web  site  provides  links  to  multiple  SOA  Web 
sites,  as  well  as  information  on  SOAs.  There  is  no  widely  agreed- 
upon  definition  of  SOA  other  than  its  literal  translation  that  it 
is  an  architecture  that  relies  on  service-orientation  as  its  funda¬ 
mental  design  principle.  Service  orientation  describes  an  archi¬ 
tecture  that  uses  loosely  coupled  services  to  support  the  require¬ 
ments  of  business  processes  and  users.  Resources  on  a  network 
in  a  SOA  environment  are  made  available  as  independent  ser¬ 
vices  that  can  be  accessed  without  knowledge  of  their  underly¬ 
ing  platform  implementation. 


More  Online  from  CrossTalk 

Crosstalk  is  pleased  to  bring  you  this  additional  article 
with  full  text  at  <www.stsc.hill.af.mil/crosstalk/2007/09/index.html>. 


SOA  Security  Reference  Model 

Nataraj  Nagaratnam,  Anthony  Nadalin,  Janet  Mostow  and 

Sridhar  Muppidi 
IBM  Software  Group 

Merely  securing  the  perimeter  with  firewalls  or  routers  is  not  suf¬ 
ficient  for  a  flexible  business.  Security  remains  one  of  the  biggest 
challenges  given  the  complexity  of  a  Service-Oriented 
Architecture  (SOA)  based  environment,  due  to  loose  coupling  of 
services  and  applications  and  their  possible  operations  across  trust 


boundaries. 

Security  must  be  designed  to  cover  the  entire  SOA  environ¬ 
ment,  with  services  and  applications  capable  of  participating  in 
the  enterprise  security  via  security  services.  In  addition,  security 
must  be  factored  into  the  SOA  life  cycle,  reflecting  the  fact  that 
security  is  a  business  requirement,  and  not  just  a  technology 
attribute.  This  article  discusses  a  scenario  and  identifies  a  set  of 
security  requirements.  It  then  talks  about  capabilities  that  can  be 
used  to  address  those  needs. 
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Evolution  in  Action  -  Building  Up  to  a 
Service-Oriented  Architecture 


Because  this  column  has  to  be  written  several  months  in 
advance,  I  am  writing  it  at  the  2007  Systems  and  Software 
Technology  Conference  (SSTC)  in  Tampa  Bay,  Florida.  Talk 
about  a  bunch  of  geeksM  I  mean  this  in  a  nice  way,  of  course 
(because  I  know  I  am  one). 

Seriously,  the  SSTC  had  some  great  exhibits  this  year.  Most  of 
the  exhibits,  of  course,  displayed  software  products  designed  to 
help  you  develop  and  maintain  your  systems,  which  leads  me  to 
the  topic  of  this  column:  Service-Oriented  Architectures  (SOAs). 
SOAs  are  loosely  defined  as  an  environment  made  available  as  inde¬ 
pendent  services  that  can  be  accessed  without  knowledge  of  their  underlying 
plaform  implementatiorh .  Interoperability  —  what  a  concept.  You 
see,  it’s  all  evolutionary,  because. ... 

IN  THE  BEGINNING  was  machine  language.  You 
remember? 

BALR  R14,  R15 
USING  V? 

The  problem  was  that  machine  language  was  so  closely  tied  to 
the  machine  that  it  wasn’t  even  transportable  across  different 
machines  from  the  same  vendor.  Thus,  programs  that  ran  on  an 
IBM  1401  with  a  specific  memory  configuration  would  not  even 
transport  to  another  differently  configured  1401.  What  we  need¬ 
ed  was . . . 

...  HIGH-LEVEL  LANGUAGES.  FORTRAN,  COBOL, 
RPG,  and  eventually,  languages  like  C  and  Standardized  are  trans¬ 
portable  (within  limits)  from  one  machine  to  another.  Which 
leads  to.... 

. . .  PARAMETER  PROBLEMS.  If  a  C  program  passed  two 
parameters  (such  as  an  integer  and  a  real),  but  the  receiving  sub¬ 
program  read  them  as  a  real  followed  by  an  integer,  it  would  try 
and  work  and  usually  fail  because  the  data  was  interpreted  incor¬ 
rectly.  When  I  taught  at  the  US.  Air  Force  Academy  back  in  the 
’80s,  we  used  Pascal  and  always  taught  that  parameters  had  to 
agree  (between  caller  and  callee)  in  number,  order,  and  type. 
Early  on,  software  engineers  found  out  that  about  75  percent  of 
all  errors  occurred  not  directly  in  the  code  but  in  the  code  inter¬ 
faces.  So  we  tried  to  emphasize  to  students  to  always  check  the 
number,  order,  and  type  of  parameters.  Of  course,  telling  them 
to  check  their  parameters  was  not  as  good  as  . . . 

...  ENFORCED  PARAMETERS  AND  STRONGLY 
TYPED  LANGUAGES,  Ada  (and  its  successors),  C++  (to  an 
extent),  and  Java.  Want  to  pass  four  parameters  that  consist  of 
two  reals  and  two  floats?  Then  let  the  compiler  and  run-time 
environment  enforce  the  parameter  number,  order,  and  type.  If 
you  tried  passing  them  in  the  wrong  order,  then  the  program 
would  return  an  error  and  not  attempt  to  convert  incorrect  data. 
In  fact,  if  you  accidentally  try  and  pass  a  floating  point  number 
as  an  integer  (and  perhaps  lose  precision),  the  compiler/ runtime 
environment  will  also  prevent  that,  giving  you  a  better  chance  at 
correct  programs  and  preventing  accidental  parameter  type  mis¬ 
matches.  However,  as  programs  grew  larger  and  larger  (and  sys¬ 
tems  of  systems  evolved)  the  interfaces  between  multiple  sub¬ 
programs  became  larger  and  larger  (with  more  and  more  para¬ 
meters),  which  leads  to. . . 

...  STANDARDIZED  LIBRARIES.  Why  bother  to  pass  a 


zillion  parameters  to  a  handwritten  user  display  procedure  (which 
took  lots  of  time  to  write),  when  a  completely  pre-written 
Graphical  User  Interface  was  available?  All  you  have  to  do  is  use 
an  object-oriented  language  and  development  environment, 
spend  a  little  time  researching  which  services  and  libraries  are 
available,  and  then  inherit/instantiate  the  code  you  need.  Don’t 
write  it  —  REUSE  IT!  However,  to  make  standardized  libraries 
and  reusable  code/ services  efficient  and  cheap,  we  really  need¬ 
ed.  . . 

...  STANDARDIZED  OPERATING  SYSTEM  SER¬ 
VICES.  Back  in  the  ’80s  and  ’90s,  you  couldn’t  trust  the  operat¬ 
ing  system  (OS)  code.  You  used  the  OS  to  load  your  program, 
but  then  you  wanted  to  write  your  own  memory  management, 
real-time  scheduling,  and  other  critical  services.  However,  as  OSs 
became  more  and  more  standardized,  they  provided  more  and 
more  services.  In  fact,  what  you  wanted  was  a  reasonably  secure 
and  reliable  set  of  services  that  would  let  you  not  just  reuse  code, 
but  also  let  you  utilize  reusable  services.  Which  is  why  we  need. . . 

...  SERVICE-ORIENTED  ARCHITECTURES.  It’s  all 
about  saving  time  and  money.  High-level  languages  are  cheaper 
than  assembly  language.  Standardized  OSs  give  you  services  that 
are  cheaper  than  roll  your  own.  Reusing  code  saves  you  time  and 
money.  So  why  not  have  take  advantage  of  independent  services  with 
defined  interfaces  that  can  be  caked  to  perform  their  tasks  in  a 
standard  way,  without  the  service  having  foreknowledge  of  the 
calling  application,  and  without  the  application  having  or  needing 
knowledge  of  how  the  service  actually  performs  its  tasks.  SOAs 
are  an  evolutionary  step  above  standardized  OS  services,  and  can 
be  regarded  as  a  style  of  information  systems  architecture  that  enables  the 
creation  of  applications  that  are  built  by  combining  loosely  coupled  and  inter¬ 
operable  serviced.  All  of  the  good  software  engineering  buzzwords 
that  we  have  tried  to  teach  over  the  last  20  or  so  years  are  inher¬ 
ent  in  an  SOA:  loosely  coupled,  interoperable,  abstractions,  and 
enforced  interfaces. 

There  you  have  it  —  engineering  evolution  in  a  nutshell.  By 
using  an  SOA,  you  will  achieve  savings  in  both  development  cost 
and  time.  As  a  single  example,  interprocess  communication  and 
network  interface  issues  will  have  been  solved  in  an  SOA  (and 
when  they  need  updating,  the  SOA  will  be  updated,  not  your  pro¬ 
gram!).  It’s  just  like  plagiarism  but  without  the  moral  dilemma. 

Why  do  you  want  to  reinvent  the  wheel  when  there  are 
already  perfectly  good  wheels  that  somebody  else  has  already 
built? 

—  David  A.  Cook,  Ph.D. 

The  AEgis  Technologies  Group,  Inc. 

dcook@aegistg.com 

Notes 

1.  Well,  where  else  could  you  find  an  audience  that  appreciates 
the  following?  ‘'Obviously,  God  LOVES  the  C  programming 
language,  because  in  Genesis  1,  verse  2,  it  clearly  states  that 
the  earth  was  without  form,  and  it  was  VOID.”  And,  for  you 
FORTRAN  programmers:  “God  is  REAL  (unless  explicitly 
declared  INTEGER).” 

2.  Wikipedia  <http://en.wikipedia.org/wiki/service-oriented_ 
architecture  >. 
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Software  Assurance 
Program 


Software  is  essential  to  enabling  the  nation’s  critical  infrastructure.  To 
ensure  the  integrity  of  that  infrastructure,  the  software  that  controls  and 
operates  it  must  be  reliable  and  secure. 

Visit  http://www.us-cert.gov/SwA  to  learn  more 
about  the  software  assurance 
program  and  how  you  can 
become  more  involved 

Security  must  be  "built  in" 
and  supported  throughout 
the  lifecycle. 

Visit 

http://BuildSecurityln.us-cert.gov  to 
learn  more  about  the  practices  for 
developing  and  delivering  software  to 
provide  the  requisite  assurance. 

Sign  up  to  become  a  free  subscriber 
and  receive  notices  of  updates. 


http://www.us-cert.gov/SwA 

The  Department  of  Homeland  St  curity  provides  the  public-private  framework 
for  shifting  the  paradigm  from  “patch  management”  to  “software  assurance.” 


Crosstalk  y  517  SMXSXMXDEA 
6022  Fir  AVE 
BLDG  1238 

Hill  AFB,  UT  84056-5820 


PRSRT  STD 
U.S.  POSTAGE  PAID 
Albuquerque,  NM 
Permit  737 


Crosstalk  is 
co-sponsored  by  the 
following  organizations: 


Homeland 

Security 


